[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] Re: canonicalization
At 11:07 AM -0500 3/4/02, Simon St.Laurent wrote: >Its lack of a clear processing model (when do these things get processed >and what is there relation to other W3C specs) and its content-polluting >fallback suggest some serious potential for chaos. > But there is a very clear processing model. It only becomes unclear when you read things into the specs that just aren't there. An xinclude:include element is an element. It is treated like any other element, nothing more, nothing less. Like all other elements various processes may choose to treat this element in a certain way. For instance, a stylesheet might color it blue. An XSLT transform might copy it intact while changing other elements. A DTD might say it's an empty element. A schema might say it has type xsd:string. A SAX program might log the URLs found in xinclude:include href attributes to a database. And there are about a thousand other things that can happen. But it's still just an element. One thing a process that operates on well-formed XML documents that have xinclude:include elements might do is replace those elements with the content of the documents they point to. Doing this creates a new and different document, which other processes may then operate on. This is similar in concept to XSL transformation or XML encryption. An operation is performed on an XML document which produces a new and different XML document. The document that comes out of transformation or encryption is not the same document that went in. The document that comes out of inclusion is also not the same document that went in. There shouldn't be any confusion here. At each step of the process there is a well-formed XML document. The W3C specs are well-written and clear. They define exactly what happens when canonicalization, XSL transformation, encryption, and various other operations are applied to an XML document. They do not define in what order these operations have to be applied because it's not necessary. Not all the operations have to be performed all the time. Not everyone will want to perform them in the same order. >Adding this to core of XML, as some have suggested for an XML 2.0, seems >like a good way to ensure that developers are as mystified by missing >content in XML 2.0 (per XInclude) as they were in XML 1.0 (per NV >parsers and external entities). If anything, XInclude seems likely to >afflict a lot more of these kinds of problems. I don't remember hearing those suggestions, and I'd certainly oppose them. I don't think an XML 2.0 that's in any way incompatible with XML 1.0 is a good idea. Even if it were, I don't think inclusion should be part of it. Layering functionality is a good thing. -- +-----------------------+------------------------+-------------------+ | Elliotte Rusty Harold | elharo@m... | Writer/Programmer | +-----------------------+------------------------+-------------------+ | The XML Bible, 2nd Edition (Hungry Minds, 2001) | | http://www.cafeconleche.org/books/bible2/ | | http://www.amazon.com/exec/obidos/ISBN=0764547607/cafeaulaitA/ | +----------------------------------+---------------------------------+ | Read Cafe au Lait for Java News: http://www.cafeaulait.org/ | | Read Cafe con Leche for XML News: http://www.cafeconleche.org/ | +----------------------------------+---------------------------------+
|
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
|