W3C home > Mailing lists > Public > xproc-dev@w3.org > September 2009

Re: [xml-dev] Serialization of XDM - Use cases / Proposal

From: Kurt Cagle <kurt.cagle@gmail.com>
Date: Mon, 21 Sep 2009 09:50:15 -0700
Message-ID: <6fa681b10909210950y639784ebi60304d1d15fbeeb8@mail.gmail.com>
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>
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 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 21 September 2009 16:51:03 GMT