Cart
|
[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] Re: XPath 1.5? (was RE: typing and markup)
 Hi David, >> Since this is compile-time assessment of the expressions in the >> stylesheet, I think that the answer is to not import a schema to >> the stylesheet in the first place, > > Well yes, but that answer's the same as Jonathan's. If someone > argues that supporting schema complex types, bloats the spec, > complicates the use of the language, and provides lots of > undesirable side effects. Being told that you can use Xpath/XSLT > without using that feature is I suppose better than nothing, but > hardly a justification for the schema complex type support being > there in the first place. I wasn't attempting to justify it. It appeared to me that you were saying that Schematron would be unusable because of the support for complex types; I was simply pointing out that it is still completely usable. I agree with the other parts of your argument. >> I can't see anything in the XSLT 2.0 WD that says that, during >> compilation, it will access a particular instance document's schema >> and use that to optimise queries. > > Neither could I actually, but this so far has been the only > justification offered for the provision of strong typing based on > schema complex types, so if it is Xquery only, what's it doing in > Xpath? Frankly, I don't know. There is a "should" requirement for XPath 2.0 to enable users to select elements or particular types (or belonging to particular substitution groups). This is supported by the "instance of" operator and "SequenceType checking" which isn't currently specified completely. (If that was lightweight then it wouldn't be much of a problem, but I have the horrible suspicion that SequenceType checking is going to involve it's own validation model, as in the XQuery Semantics document...) Perhaps there's something in that requirement that entails strong typing based on schema complex types? Statically checking and optimising path expressions based on the complex type definitions in a schema doesn't seem to be on the requirements for XPath 2.0, although there is a requirement that XSLT 2.0 "Could Improve Efficiency of Transformations on Large Documents". I don't think that the kind of optimisations we're talking about would have much effect there, however. Or perhaps it's just that the WGs are trying to make XPath 2.0 as large a subset of XQuery as they can. Oh sorry, was that a rhetorical question? >> If a processor substituted aaa/bbb for the empty sequence on the >> assumption that the source document was completely valid, there >> would be a rather strange situation where the data model contained >> an element that was inaccessible from the stylesheet. > > You say it's strange, and I agree, but neither of us are on the WG, > It's hard to understand how the argument that the type system allows > compile time optimisation (if it is true) can fail to lead to this > strange situation. Well, it could lead instead to a complete refusal of the processor to transform the document. Cheers, Jeni --- Jeni Tennison http://www.jenitennison.com/ 
|
PURCHASE STYLUS STUDIO ONLINE TODAY!Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced! 
Download The World's Best XML IDE!Accelerate XML development with our award-winning XML IDE - Download a free trial today! Subscribe in XML format
|
|||||||||
