[XSL-LIST Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message]

Re: xinclude in xslt2

Subject: Re: xinclude in xslt2
From: Erik Wilde <net.dret@xxxxxxxx>
Date: Sat, 19 Aug 2006 11:18:09 -0700
dret fax contacts us
hello.

Erik Wilde wrote:
From: Colin Paul Adams <colin@xxxxxxxxxxxxxxxxxx>
"Erik" == Erik Wilde <net.dret@xxxxxxxx> writes:
    Erik> apart from that, i cannot imagine what the hard parts should
    Erik> be, but maybe i am a bit to naive. anyway, i would be very
    Erik> happy to be pointed to a list of potential problems before i
    Erik> get started.
I seem to recall that there are parts of the infoset that XInclude
needs that an XSLT processor never gets to see, as they aren't in the
XPath Data Model. But my memory is rather vague on this.
if anybody could mention if this really is the case, i would be most grateful. http://www.w3.org/TR/xinclude/#infoset to me looks as if the "must" parts are all satisfied by the infoset view of xslt, whereas the "may" parts ("include history" and "language" properties) definitely are a problem. but they are optional.

i probably should have looked into other parts of the xinclude spec as well (the #infoset part does not really list everything that is needed). in the sections about unparsed entities and notations, it is said that these items must be merged (while discarding duplicates). this is not good, because these items are not visible in xslt. this is probably what you were referring to. so looks as if you were right. however:


there used to be a feature in xslt 2.0 which could have saved us, at least as an optional feature (does/did saxon support this? or any other xslt 2.0 proecssor?):

http://www.w3.org/TR/2001/WD-xslt20-20011220/#lexical-representation

unfortunately, this useful section has been removed from the spec. does anybody know the reason? i do think that xslt's somewhat reduced view of an infoset in principle is a good thing, but it would have been nice to have the opportunity to get to the other parts as well, at least as an optional feature. xinclude is a good example for that.

so this means that xslt 2.0 is probably good for implementing an xinclude processor as mentioned in the #infoset section of the xinclude spec, but unfortunately this section is not complete. it is my understanding that a conforming xinclude processor must also process unparsed entity declarations and notation declarations, which are a problem. with xslt 2.0 "lex:" namespace, this would have been possible, without this, i think there is no easy way how to handle it.

since i (and probably 99.9999% of all xml users) do not use unparsed entities and notations, i would be happy to have an xinclude processor not supporting them, but it looks as if an xinclude processor is not allowed to ignore them. there are no *must* clauses in the sections about unparsed entities and notations, however, but i guess this is more sloppy wording than meaning that they are not mandatory.

so, from all of this i include that i will probably produce a non-conforming xinclude processor in xslt 2.0, which could be extended to a conforming xinclude processor rather easily if the "lex:" namespace were supported by the underlying xslt processor. if not, this is not a problem for me and the majority of other potential users of xinclude. it would be nice if xinclude would somehow reflect the xslt-view of xml (maybe as a possible conformance level).

thanks for any additional commant and kind regards,

erik wilde     tel:+1-510-6421464 - fax:+1-510-6425814
     dret@xxxxxxxxxxxxxxxxx - http://dret.net/netdret/
     School of Information - UC Berkeley (ISchool/UCB)

Current Thread

PURCHASE STYLUS STUDIO ONLINE TODAY!

Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced!

Buy Stylus Studio Now

Download The World's Best XML IDE!

Accelerate XML development with our award-winning XML IDE - Download a free trial today!

Don't miss another message! Subscribe to this list today.
Email
First Name
Last Name
Company
Subscribe in XML format
RSS 2.0
Atom 0.3
Site Map | Privacy Policy | Terms of Use | Trademarks
Free Stylus Studio XML Training:
W3C Member
Stylus Studio® and DataDirect XQuery ™are products from DataDirect Technologies, is a registered trademark of Progress Software Corporation, in the U.S. and other countries. © 2004-2013 All Rights Reserved.