another, more radical, possibility

classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

another, more radical, possibility

Bruce D'Arcus-3
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"/>
         <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 XML
standpoint, but it probably fits better non-XML programming
environments (indeed, the thinking is partly motivated by working on
the 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 signal
hierarchy. 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 group
formatting 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, I
might as well get it over with quickly and not look back. Not
surprisingly, I'm reluctant to do so without a few votes of confidence!
Maybe I'm being a little crazy!

Bruce



Reply | Threaded
Open this post in threaded view
|

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

Bruce D'Arcus-3
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



Reply | Threaded
Open this post in threaded view
|

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

Bruce D'Arcus-3
In reply to this post by Bruce D'Arcus-3
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