OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

 


 

   Re: [xml-dev] XPath 1.5? (was RE: [xml-dev] typing and markup)

[ Lists Home | Date Index | Thread Index ]


> Here's one such issue: I want to write a query or a transform whose output 
> is guaranteed to be XHTML. I don't want to validate my output each time to 
> see if it succeeded.

I have yet to see this done for any seriously complicated transform.
If the transformation is sufficiently simple then you could do this
without the type system, but are you really expecting to be able to
typecheck a function mapping (say) docbook to XHTML and guarantee that
given a valid docbook instance a valid XHTML instance will come out?

This may be just about possible with the XQuery style, but is highly
dubious with the recursive template style in XSLT. You really don't have
a good enough handle on when the templates will fire in order to
typecheck the whole transform (as opposed to individual component
functions). This is just part of the general problem, Xquery appears to
have loaded a lot of baggage on XSLT/Xpath for which the famous "use
cases"  are hard to find...

> Nothing in our spec requires you to do this. [define schema types]

No of course, but my point is that while I can see a lot of use using
dtd/schema to constrain authoring, and can see use of schema simple
types to allow provision of type aware functions for sorting and
arithmetic, I can see no use for schema complex types at
transformation-time. 

The fact that I don't _need_ to use them is hardly justification for them
being there.  Your guarantee of producing valid output _would_ be a
justification but as I say, I don't believe that holds in XSLT (and
remain to be convinced it holds for serious sized Xquery either).

> I would find it very useful to know if a transform will always produce an 
> instance that will validate against some schema. Thats why we support 
> complex types. This story is currently more compelling for XQuery than for 
> XSLT, though, because the types for queries have been worked out in more 
> detail.

I'd say it is plausible in Xquery and totally uncompelling in XSLT.
But even if we accept your wording, where is the "use case" for foisting
all this stuff onto Xpath and so XSLT?

> Indeed.
Yo! we agree on something:-)


> This question has not been answered, it is an open issue. My own view is 
> that if the validation fails, XPath 2.0 and XQuery 1.0 should have 
> undefined behavior.

So as one of the authors of Xpath 2 you are happy to casually break one
of the most innovative and successful uses of Xpath 1? Interesting.

David

_____________________________________________________________________
This message has been checked for all known viruses by Star Internet
delivered through the MessageLabs Virus Scanning Service. For further
information visit http://www.star.net.uk/stats.asp or alternatively call
Star Internet for details on the Virus Scanning Service.




 

News | XML in Industry | Calendar | XML Registry
Marketplace | Resources | MyXML.org | Sponsors | Privacy Statement

Copyright 2001 XML.org. This site is hosted by OASIS