Re: [xsl] Partial Implementation of XInclude include element

["W. Eliot Kimber" <eliot at isogen dot com>]

Elliotte Rusty Harold wrote:
> 
> At 5:00 PM -0500 9/22/02, W. Eliot Kimber wrote:
> >I have developed a simple technique for implementing XInclude's include
> >element as part of a larger style sheet so that you don't have a to do a
> >two-stage transform. I haven't tested this extensively, but I don't see
> >any reason why it shouldn't work for any document set, although I may
> >have overlooked some subtle issue.
> >
> 
> 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?

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.

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. 

For example, I might want to use parse='text' to include some source
code into a document. Fine, parse='text' lets me do that. But wouldn't
it be cooler if I could include the source code as a "parsed" node set
where the nodes reflect the abstract structure of the source code (e.g.,
the AST of Java or Python or IDL)? Given that most modern languages
provide code for parsing themselves, it would be a simple matter in most
cases to bind the language's AST to some generic node representation.
But XML (and by extension, XSLT) gives us no direct way to do that. So
while parse='text' might satisfy the requirement of doing things like
including non-XML, text-based data into a document, in most cases I'd
really be more likely to do some sort of XMLification on the imported
data first anyway, just so I can do more interesting stuff with it in my
XSLT.

Cheers,

E.
-- 
W. Eliot Kimber, eliot@isogen.com
Consultant, ISOGEN International

1016 La Posada Dr., Suite 240
Austin, TX  78752 Phone: 512.656.4139

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