Re: [dev-biblio] another, more radical, possibility

[Matthias Basler]

Zitat von Bruce D'Arcus [EMAIL PROTECTED]:

 Am trying to wrap up the new version of CSL and would like some
 feedback.

 Here's another, even flatter, and more generic possibility:

metadata-type name=book
  formatting-def name=author alternate=editor/
  formatting-def name=year prefix= ( suffix=) /
  formatting-def name=title font-style=italic suffix=./
  formatting-def name=editor/
[...]

Hi Bruce

  Just some weeks ago I read on
http://www.w3schools.com/xml/xml_attributes.asp that it is good practice to
use elements for data and attributes for metatata only (e.g. language or id
or the font-style attribute as in the example above). I like to agree with
this:
  An XML structure based on elements is extensible in the future. You can later
define additional children or new attributes when necessary. If data is stored
in an attribute, this attribute cannot easily be extended to hold more
information in the future.
  Using usual XML parsers as I know them from Java it is not easier or more
difficult to parse or write elements than attributes. So except a slighly
smaller file you wouldn't gain much using these parsers. Of course I don't have
experience with Ruby or Phython but I don't expect it to be very different.

Anyway, my opinion is NOT to use such flattened layout.

P.S. Sorry for the long delay, but our mailing system had a crash last weekend.
Hope this helps.
Matthias Basler
[EMAIL PROTECTED]


This mail was sent through http://webmail.uni-jena.de

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [dev-biblio] another, more radical, possibility

[pt]

Looks ok to me, but have you considered whether an attribute is the best way to represent the prefix and suffix? What if they actaully require some formatting in some environments?So would you ever need: formatting-def name=year
prefixbold(/bold/prefixsuffixbold)/bold/suffix/formatting-defOn 2/6/06, 
Bruce D'Arcus [EMAIL PROTECTED] wrote:
Am trying to wrap up the new version of CSL and would like somefeedback.Here's another, even flatter, and more generic possibility: metadata-type name=book formatting-def name=author alternate=editor/
 formatting-def name=year prefix= ( suffix=) / formatting-def name=title font-style=italic suffix=./ formatting-def name=editor/
 formatting-group prefix=( suffix=) formatting-def name=publisher-place/ formatting-def name=publisher-name prefix=:/
 /formatting-group/metadata-type metadata-type name=chapter formatting-def name=author alternate=editor/
 formatting-def name=year prefix= ( suffix=) / formatting-def name=title font-style=italic suffix=./ formatting-def name=container-title prefix= /
 formatting-def name=container-editor/ formatting-group prefix=( suffix=) formatting-def name=container-publisher-place/
 formatting-def name=container-publisher-name prefix=:/ /formatting-group/metadata-type metadata-type name=article
 formatting-def name=author alternate=editor/ formatting-def name=year prefix= ( suffix=) / formatting-def name=title font-style=italic suffix=./
 formatting-def name=container-title prefix= / formatting-group prefix=( suffix=) formatting-def name=volume prefix=v/
 formatting-def name=issue prefix=n/ formatting-def name=month_day prefix=, / /formatting-group/metadata-type
The above is less elegant and easily controlled from a purely XMLstandpoint, but it probably fits better non-XML programmingenvironments (indeed, the thinking is partly motivated by working onthe port to Ruby, where I have objects that look something like the
above), and would be easier to integrate into existing styling systems(e.g. ODF). It's also more flexible.The idea would be to use conventions on the name attributes to signalhierarchy. The hyphen would denote a relation.So, for example,
container-title does the same thing as the existing nested elements.Likewise for the publisher-* names.I add the formatting-group element to retain the ability to groupformatting where needed, but leave it totally flexible what would go in
those groups.Any opinions? This would be a kind of radical change, and if I do it, Imight as well get it over with quickly and not look back. Notsurprisingly, I'm reluctant to do so without a few votes of confidence!
Maybe I'm being a little crazy!Bruce-To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]-- Peter (pt) SeftonToowoomba 4350
Queensland, AustraliaPhone: +61 4 1032 6955Web: http://ptsefton.comEmail: [EMAIL PROTECTED]