Re: [xsl] Partial Implementation of XInclude include element

Subject: Re: [xsl] Partial Implementation of XInclude include element
From: Elliotte Rusty Harold <elharo@xxxxxxxxxxxxxxx>
Date: Sun, 22 Sep 2002 20:53:35 -0400
At 6:50 PM -0500 9/22/02, W. Eliot Kimber wrote:


How do you (or do you?) handle parse="text"?

I don't. Like I said, it's a partial implementation. But I guess it would require an extension element to actually get the data value of the file in order to implement parse='text', right?

Pretty much. XSLT 2.0 will probably be able to do this, but in 1.0 you need and extension function.


This is an example of how the lack of an overarching data model in XML
land causes problems: it should really be a function of the data type of
the thing included to determine how it is interpreted or it should be
indicated through reference to some sort of interpretation definition.

Lord, no. It's indicative of the fact that XSLT 1.0 doesn't have a loadTextFile() function, nothing more. Some fancy data model that wouldn't fit 90% of the time wouldn't help at all. In this very use case, for example, I can (and do) load the same XML document in one place as XML and in another place as text. Which I do depends totally on whether I want the XML for its own sake or the XML for an example in my book. The XML document itself, as well as any sort of intrinsic type it has in the local file system or HTTP header, cannot and does not know how I intend to use it.


In HyTime, we solved this problem with the general grove model coupled
with a way to say what property set and grove constructor to use for a
particular external entity. We could do this because we had defined all
the grove infrastructure so that there was a definitional framework in
which it might make sense to say, for example, "use the 'plaintext'
property set and grove constructor to interpret this file, regardless of
its nominal data type". The downside of course was that we had to define
all the grove infrastructure, which is a huge complicating factor. XML
keeps things simple by having only two data types: XML and not-XML. But
that simplicity has a cost as well.

XML doesn't have two data types. It has one: XML. That's all it knows about. You're blaming XML for the failures of XSLT. XML is about XML. It does not and should not define anything beyond that. If you have a use case for converting non-XML data into XML, then use a tool that does that. It's not XML's job.
--


+-----------------------+------------------------+-------------------+
| Elliotte Rusty Harold | elharo@xxxxxxxxxxxxxxx | Writer/Programmer |
+-----------------------+------------------------+-------------------+
|          XML in a  Nutshell, 2nd Edition (O'Reilly, 2002)          |
|              http://www.cafeconleche.org/books/xian2/              |
|  http://www.amazon.com/exec/obidos/ISBN%3D0596002920/cafeaulaitA/  |
+----------------------------------+---------------------------------+
|  Read Cafe au Lait for Java News:  http://www.cafeaulait.org/      |
|  Read Cafe con Leche for XML News: http://www.cafeconleche.org/    |
+----------------------------------+---------------------------------+

XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list


Current Thread