Style duplication

CSL Development
41

OK, Dan, am updating the metadata section of the schema. I’ve checked in
the enhanced cs:source element based on your suggestion.

But I have a couple questions on the rest …

I’ve basically copy-and-pasted the Atom schema definition, and am now
adapting it to CSL. Here’s where I’m at:

info-link =
element cs:link {
attribute href { xsd:anyURI },
attribute rel { atomNCName | atomUri }?,
attribute type { atomMediaType }?,
attribute hreflang { xsd:language }?,
attribute title { text }?,
attribute length { text }?,
string
}

So:

a) should we constrain the rel values, and if so, what should they be?

Can definitely remove atomUri and limit to a few fixed values. Maybe
“source”, “template”, “homepage” and “documentation”?

A journal that uses APA:

<link rel="documentation" href="http://www.foo.org/citation_guide.html"

A journal with a style based on (but differing slightly from) APA would
have the following line in place of the rel=“source” line above:

There might be clearer words for “source” and/or “template”.

b) if we need “type” shall we constrain the values, and if so, what
should they be?

Should probably keep “type” allowing any MIME type, since the
documentation might be a PDF, Word doc, OO doc, etc., and it’d be useful
to know that from the repo. “length” for the same reasons.

c) in general, anything else we can remove?

I don’t think we need “title”. Probably should keep “hreflang”.

While we’re at it, can we allow and to be empty so
that leaving them blank and letting a repo auto-set/update them doesn’t
cause a validation error?

42

Dan Stillman wrote:

a) should we constrain the rel values, and if so, what should they be?

Can definitely remove atomUri and limit to a few fixed values. Maybe
“source”, “template”, “homepage” and “documentation”?

A journal that uses APA:

<link rel="documentation" href="http://www.foo.org/citation_guide.html"

A journal with a style based on (but differing slightly from) APA would
have the following line in place of the rel=“source” line above:

There might be clearer words for “source” and/or “template”.

This all looks good. Does anyone have any alternatives to “source” and
“template”? Earlier I was using “basedOn” for the latter.

For the record, this would in part be an alternative to Simon’s
suggestion to put a source attribute on the root.

b) if we need “type” shall we constrain the values, and if so, what
should they be?

Should probably keep “type” allowing any MIME type, since the
documentation might be a PDF, Word doc, OO doc, etc., and it’d be useful
to know that from the repo. “length” for the same reasons.

OK.

c) in general, anything else we can remove?

I don’t think we need “title”. Probably should keep “hreflang”.

While we’re at it, can we allow and to be empty so
that leaving them blank and letting a repo auto-set/update them doesn’t
cause a validation error?

Hmm … except as I just recently posted on the zotero dev list, I’m not
so sure the way you’re currently handling this is working. It seems to
me the repo should be able to update an existing value on commit?

Also, if we leave it optional in the schema, we’re in fact leaving it
optional. Wouldn’t it be better to get validation errors in some interim
background process than have people publishing CSL files without this
important metadata?

Bruce

43

Dan Stillman wrote:

While we’re at it, can we allow and to be empty so
that leaving them blank and letting a repo auto-set/update them doesn’t
cause a validation error?

Hmm … except as I just recently posted on the zotero dev list, I’m not
so sure the way you’re currently handling this is working. It seems to
me the repo should be able to update an existing value on commit?

I could’ve sworn I made that change, but apparently not. It should now
update the timestamp of changed styles no matter what.

Also, if we leave it optional in the schema, we’re in fact leaving it
optional. Wouldn’t it be better to get validation errors in some interim
background process than have people publishing CSL files without this
important metadata?

I suppose. Requiring a timestamp is fine as long as we’re not too
offended by long-out-of-date timestamps in unpublished styles (including
in SVN repos) and can encourage authors just to set some arbitrary
timestamp once and forget about it rather than wasting time updating
them manually each time…

44

OK, I checked in the info metadata changes.

Bruce