[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message]

Re: canonicalization

base tag and canonicalization
On Mon, Mar 04, 2002 at 10:47:04AM -0800, Tim Bray wrote:
> At 04:36 AM 04/03/02 -0500, Daniel Veillard wrote:
> >  It's just a matter of API level. As parts get used more they
> >gets forged as API. Better building API at a syntax level than 
> >in the programing language syntax. I call this sedimentation...
> That's precisely what I'm disagreeing with... I'm becoming
> more & more convinced that inclusion and aggregation have so
> much application-specific hair, and the cost of trying to 
> model them generally is so high, that we should just kick
> them out of the syntax and at the level of *interoperability*,
> we should talk in terms of whole fully composed XML documents.

  I would be tempted to tease and ask what is an XML document (would
the TAG ever find the answer ;-) . I also note that in use case like
the Jabber protocol, you never end-up with a "fully composed document"
it only exists once the processing is finished and that it had become
  But to stay in line with the previous discussion, the cost of the
modelling has IMHO been mostly done once the Infoset was defined. At that
point one have a model of a document instance and it becomes possible
to define *one* semantic to document merging. I doubt that there is
any disagreement about the fact that defining that merge operation is
an useful base concept. As you pointed disagreement can arise about
variation in semantic about that operation. And in such case defining
one predefined semantic, the XInclude one help those who can use it. 
The debate is not whether to build it into syntax and infrastructure, 
but whether it's possible to define one semantic which fits a large user
base. So far with the added ID fixup I personally find it useful, it's
in CR and there is already some implementations. The key point is that
it doesn't prevent people from using perl/python/whatever language to
define their own merging semantic if they have a different need. And
XInclude won't be less interoperable than those custom processing tools.

  You say "the cost is too high compared to the potential user base",
I just say "maybe, but the work is mostly done and it may get more
users than what you expect".


Daniel Veillard      | Red Hat Network https://rhn.redhat.com/
veillard@r...  | libxml Gnome XML XSLT toolkit  http://xmlsoft.org/
http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/


Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced!

Buy Stylus Studio Now

Download The World's Best XML IDE!

Accelerate XML development with our award-winning XML IDE - Download a free trial today!

Don't miss another message! Subscribe to this list today.
First Name
Last Name
Subscribe in XML format
RSS 2.0
Atom 0.3

Stylus Studio has published XML-DEV in RSS and ATOM formats, enabling users to easily subcribe to the list from their preferred news reader application.

Stylus Studio Sponsored Links are added links designed to provide related and additional information to the visitors of this website. they were not included by the author in the initial post. To view the content without the Sponsor Links please click here.

Site Map | Privacy Policy | Terms of Use | Trademarks
Free Stylus Studio XML Training:
W3C Member
Stylus Studio® and DataDirect XQuery ™are products from DataDirect Technologies, is a registered trademark of Progress Software Corporation, in the U.S. and other countries. © 2004-2013 All Rights Reserved.