[
Lists Home |
Date Index |
Thread Index
]
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@metalab.unc.edu | 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/ |
+----------------------------------+---------------------------------+
|
