- From: Kurt Cagle <kurt.cagle@gmail.com>
- Date: Mon, 21 Sep 2009 09:50:15 -0700
- To: Michael Kay <mike@saxonica.com>
- Cc: "David A. Lee" <dlee@calldei.com>, Philippe Poulard <philippe.poulard@sophia.inria.fr>, rjelliffe@allette.com.au, xml-dev@lists.xml.org, XProc Dev <xproc-dev@w3.org>
- Message-ID: <6fa681b10909210950y639784ebi60304d1d15fbeeb8@mail.gmail.com>
This is the second time that I've seen the use of XSLT as a formalization mechanism outside of its original scope that I have to admit liking, the first being in the area of creating a consistent documentation dump format for EX*. I was asleep at the switch on xs:positiveInteger(5) - that one should have been obvious, and it wasn't. Spending too much time in RDF land of late. Concerning eval - while a formal eval() is likely not in the cards for XQuery/XSLT2.1, I seem to remember hearing at Balisage that there was some discussion about a function constructor that would accomplish much the same thing as part of the higher order function retooling - anyone know anything about this? Kurt Cagle Managing Editor http://xmlToday.org On Mon, Sep 21, 2009 at 7:01 AM, Michael Kay <mike@saxonica.com> wrote: > Some people have been suggesting using a subset of XQuery syntax, others > have been saying it would be better to use XML syntax. > > It occurs to me one might achieve both objectives at the same time by using > a subset of XSLT syntax. That is, we could define the syntax to be a named > xsl:template instruction containing a sequence constructor in which only the > following are permitted: > > (a) An <xsl:sequence> instruction whose select attribute contains a > constructor function with a string literal argument, for example > <xsl:sequence select="xs:positiveInteger('5')"/> > > (b) An empty <xsl:attribute>, <xsl:value-of>, <xsl:comment>, > <xsl:processing-instruction> or <xsl:namespace> instruction whose content is > constrained to use no non-literal expressions or AVTs. > > (c) An <xsl:element> or <xsl:document> instruction whose content is > constrained to hold only <xsl:element>, <xsl:attribute>, <xsl:value-of>, > <xsl:comment>, <xsl:processing-instruction> or <xsl:namespace> instructions > that themselves follow the same rules. > > There might be a need to define some additional attributes specific to the > serialization format, e.g. to represent IDness. > > > Regards, > > Michael Kay > http://www.saxonica.com/ > http://twitter.com/michaelhkay > > ------------------------------ > *From:* Michael Kay [mailto:mike@saxonica.com] > *Sent:* 21 September 2009 14:45 > *To:* 'David A. Lee' > *Cc:* 'Philippe Poulard'; 'Kurt Cagle'; rjelliffe@allette.com.au; > xml-dev@lists.xml.org; 'XProc Dev' > *Subject:* RE: [xml-dev] Serialization of XDM - Use cases / Proposal > > > > > Ouch. If this cant be done in xquery syntax then my goal of > de-serializing an XML representation using a XQuery example implementation > is out the door. > > > Here's my best shot ... > > > attribute > { fn:QName( "U" , "P:N" ) } > { my:IdType( "S" ) } (: wont work will it :( :) > > > Ok I admit I'm totally stumped. *IS* there a way to re-animate this > example using XQuery (or XSLT?) ? > I have a feeling that my goal of providing a reference implementation in > XQuery will be impossible. Not even sure how to get element type > information re-animated. > > > > I think that in XSLT, the following comes close: > > <xsl:attribute name="P:N" namespace="U" type="my:IdType" select="'S'"/> > > provided that the recipient has a schema (the correct schema) for the > global attribute declaration my:IdType. There are problems if the type is > anonymous (you might have to construct a variant of the original schema in > which all types have names). As for the isID property, it is ALMOST > redundant in XDM: it can in nearly all cases be inferred from the type > annotation. The exception is where IDness was established as a result of > DTD validation rather than schema validation. In that case, yes, I think > you're going to have difficulty reconstituting the original sequence using > tools written in XSLT or XQuery. (Actually, it hadn't occurred to me this > was one of your goals.) > > XQuery 1.0 (unlike XSLT 2.0) doesn't allow validation against a type name, > and doesn't allow validation of individual attributes. > > Other limitations of using XSLT/XQuery > > (a) neither language gives you any way of creating unparsed entities > > (b) XQuery 1.0 gives you no way of creating arbitrary namespace nodes > > > Regards, > > Michael Kay > http://www.saxonica.com/ > http://twitter.com/michaelhkay > > >
Received on Monday, 21 September 2009 16:51:02 UTC