OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

 


 

   Re: [xml-dev] Re: Genx c14n?

[ Lists Home | Date Index | Thread Index ]

Elliotte Rusty Harold:
> At 12:15 AM +0400 1/27/04, David Tolpin wrote:
> >>  [Tim Bray]
> >>   >Would anyone like to take this opportunity to shout "Yes, the world needs
> >>  this!"
> >>   >or "No, the denominator of the cost/benefit ratio is zero!".
> >>
> >>  Yes, the world needs this!
> >>
> >
> >I've realized that just saying "yes" is easy. In my opinion, the world
> >need this more than
> >
> >   - pretty printing
> >   - collapsing empty tags
> >   - ability to output doctype or xml declaration
> >   - ability to use multiple encodings
> >
> 
> It's no like these are mutually exclusive (In an API, as opposed to a 
> document). However, I personally have seen no evidence of users 

Eliotte,

they are not mutually exclusive in the list above. I didn't write 'instead',
I wrote 'more than' -- being able to generate canonical XML is more important
than being able to print pretty XML. 

> asking for canonical output. I have seen frequent cases of users 
> asking for various froms of pretty printing, the  ability to output 
> doctype or xml declaration, and the ability to use multiple 
> encodings. In fact, I am convinced that any XML API that does not 
> offer these features will be D.O.A. except for the community that 
> specifically wishes to sue canonical XML.  In effect, you will have 
> created a canonical XML API, not the generic API you were aiming for.

The point has been that ability to generate documents in multiple encodings
is less important than the ability to generate XML with default attributes
added, for example, not that multiple encodings should never be handled.

> I also note, as proof by example, that pretty much none of the Java 
> APIs you cited as making this project unnecessary for Java provide 
> canonical XML. (Well, XOM does and DOM3 may optionally do that) but 

I suppose it was Tim who cited, not David Tolpin. I also suspect this
is the cause of the problem, not the consequence. It is not used because
there are no tools, not the other way around.

> what people mostly use and all the streaming APIs produce 
> non-canonical XML. This does not seem to cause most people problems 
> most of the time. Canonical XML is a very special purpose thing, 
> which is fine as an output option, but which should not be enabled by 
> default.

Canonical XML is not used because there are few implementations without the
overhead of carrying around unneeded code and data. Many processing pipelines 
can be simplified if an XML to canonical XML filter is available; it is pity
it is not. 

Canonical XML is an option for genx. But it is a very important option; it
should be added prior to many other things. 

David Tolpin
http://davidashen.net/




 

News | XML in Industry | Calendar | XML Registry
Marketplace | Resources | MyXML.org | Sponsors | Privacy Statement

Copyright 2001 XML.org. This site is hosted by OASIS