Cart
|
[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] Re: 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. <ot> 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 useless. </ot> 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 -- 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/ 
|
PURCHASE STYLUS STUDIO ONLINE TODAY!Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced! 
Download The World's Best XML IDE!Accelerate XML development with our award-winning XML IDE - Download a free trial today! Subscribe in XML format
|
|||||||||
