Dan Stillman wrote:
A “source” attribute on the root could work, though the Atom spec
suggests a few other possibilities:
- Use “src” for the root attribute, since “source” has a different
meaning in Atom (albeit as an element).
- Use an empty element – “atom:content MAY have a
‘src’ attribute… If the ‘src’ attribute is present, atom:content MUST
be empty. Atom Processors MAY use the IRI to retrieve the content and
MAY choose to ignore remote content or to present it in a different
manner than local content.” In our case, the element would
essentially be implicit otherwise.
- Use – “atom:entry elements that
contain no child atom:content element MUST contain at least one
atom:link element with a rel attribute value of ‘alternate’.”
I worry about the flexibility of Atom in this case. We need to make a
decision here: do we stick as closely as possible to the Atom spec, or
do we focus on a clear, dedicated, grammar that can be easily
controlled, validated, etc. (and which can also be easily mapped to Atom)?
With these suggestions, I’m leaning towards the second direction of course.
Of these, would probably transpose
the best into an Atom-based repository index. (This is all a little
messy, since, from the perspective of the metadata, in a CSL
file is essentially the style definitions and in the feed
entry would either contain a sample of the style output or be empty (if
is used for the samples), with linking to the CSL file. So the quote above doesn't quite
justify using rel="alternate" to point to the source style from the
feed, but given that it still more or less "identifies an alternate
version of the resource described by the containing element," I'm fine
with it.)
The CSL info object really ought to correspond to an atom:entry.
To address an earlier question from Bruce:
Example:
Style B simply borrows Style A wholesale.
Two years later, Style B changes their style with some slight
modifications, in essence creating a custom style specific to the journal.
What happens to the styles? To the user who depends on Style B?
Journal edits Style B, removing [whatever we choose as the indicator of
external content] and adding regular CSL content. Style B’s timestamp is
updated, so when the CSL client checks for an update, it sees that
there’s no longer [an external content indicator] and uses the embedded
content instead.
(When there is [an external content indicator], the CSL client will need
to grab a copy of Style A, cache it, and check for updates to it in
addition to checking for updates to Style B. Style A should not appear
as installed in the client.)
Right, with the source link, this works.
Essentially, I was trying to suggest that each style a user might want
to “see” should have a unique ID/URI and separate files (rather than,
for example, include multiple titles in a single CSL file).
