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

[Bruce D'Arcus]

On Feb 7, 2006, at 9:50 AM, Matthias Basler wrote:

Using usual XML parsers as I know them from Java it is not easier or 
more

difficult to parse or write elements than attributes.


The issues I'm concerned about (beyond file size, which is 
substantially smaller now) are not parsing or serializing, so much as 
mapping to native objects, and GUI implementations. Beyond OOo, say one 
wanted to write a web-based CSL editor using Javascript for the logic?


I may be needlessly worrying about this; am not sure.


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


OK, thanks for the feedback.

Bruce

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

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:
>
>
>  
>  
>  
>  
[...]

Hi Bruce

  Just some weeks ago I read on
 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

[Bruce D'Arcus]

On Feb 5, 2006, at 8:58 PM, pt wrote:

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?


I originally had them as elements, but a long time back decided to 
change to attributes. My reasoning was that a) I can't really imagine 
needing that, and b) allowing it adds complexity all around. Imagine, 
for example, creating a GUI editor for it.


Also, ODF has prefix and suffix attributes in some places already.

That said, it's not like I'm 100% confident in these decisions. I think 
they involve design trade-offs, and am not always sure I'm choosing 
right (which is why these emails!).


Bruce

-
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: 
 ( )On 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:    
   
       
     
   
     
       
   
     
       
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]