> 4/29/2002 10:46:19 PM, Elliotte Rusty Harold <> wrote:
>
> >
> >
> >I could copy and paste the rest of the relevant specs, but you get
> >the idea. There's a clear path from the character representation of
> >the XML document to the source tree on which XSLT operates. There's
> >no wiggle-room for performing other processes on the document before
> >XSLT gets ahold of it.
>
> I'm afraid that this is so MUCH wiggle room that the W3C held a
> conference last year to solicit thoughts on how to deal with it.
> http://www.w3.org/XML/2001/07/XMLPM.html
>
> "Increasingly, software and specifications define processing of XML documents in terms
> of XML-to-XML or infoset-to-infoset transformations. The XML Core Working Group is
> developing the XInclude specification; the XML Linking WG has developed the XLink and
> XBase specifications, which can be viewed as ways to enrich or annotate infosets; the
> XML Schema 1.0 language defines validation and annotation with datatype and other
> information in terms of a transformation from the input infoset to the output, post-
> schema-validation infoset. The XML Query language will work on an abstract data model
> defined in terms of the infoset, rather than in terms of the surface XML syntax.
> Encryption and digital signatures must be managed at appropriate points in the
> processing chain. The list could be extended indefinitely.
>
> However, the relationship among all of these W3C specifications is unspecified -- in
> particular the sequence in which the infoset-to-infoset transformations may or must be
> performed.
>
> There is also no specification, and currently no W3C work item, for specifying how an
> author or application programmer could specify an order to the various transformations.
> Thus it appears there is a missing specification in the XML activity."
>
> As Leigh notes in http://www.xml.com/pub/a/2002/03/13/processing-model.html
> "Unfortunately seven months later there's been little in the way of visible progress."
Yes. just to make sure my position is 110% clear, I agree that:
1) The standard for XML processing plan is terribly underspecified, and that this needs urgent work.
2) That processing XIncludes at the layer immediately above parsing, and therefore as an infoset transform in the source processing for, say, XSLT or XUpdate, can in theory cause surprises, and hitches in interoperability.
My argument is that (2) is not strong enough to ban the practice entirely. First of all, perhaps it's the same thing that attracts me to Python, but I don't think that I as XSLT implementor should be playing nanny to the user. I shall give them the options, and they can sort it out. It turns out that I prefer it that way: I do a lot of hand editing of XML documents (Docbook, often) that use XInclude to incorporate other sections or source code snippets from other files. I often run use XSLT on these documents. In this way, I probably, and I'm not exaggerating, use XInclude in the XSLT input source stream once a week or more.
We need a solution to (1), and when we have it, it should offer the option to satisfy users such as I am, as well as users who have reservations about interposing layers between parsing and XSLT processing.
--
Uche Ogbuji Fourthought, Inc.
http://fourthought.com
http://4Suite.org http://uche.ogbuji.net
Track chair, XML/Web Services One (San Jose, Boston): http://www.xmlconference.com/
RDF Query using Versa - http://www-106.ibm.com/developerworks/xml/library/x-think10/index.html
WSDL and the Wild, Wild West - http://adtmag.com/article.asp?id=6004
XML, The Model Driven Architecture, and RDF @ XML Europe - http://www.xmleurope.com/2002/kttrack.asp#themodel
