Subject: Re: [xsl] Partial Implementation of XInclude include element From: "W. Eliot Kimber" <eliot@xxxxxxxxxx> Date: Sun, 22 Sep 2002 18:50:30 -0500 |
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@xxxxxxxxxx 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
Current Thread |
---|
|
<- Previous | Index | Next -> |
---|---|---|
Re: [xsl] Partial Implementation of, Elliotte Rusty Harol | Thread | Re: [xsl] Partial Implementation of, Elliotte Rusty Harol |
RE: [xsl] Can you apply a template , Robert Koberg | Date | Re: [xsl] Partial Implementation of, Elliotte Rusty Harol |
Month |