|
The first question I have in mind is how do we parse this. This one example of Michaels has me a little confused: <xsl:sequence select="xs:positiveInteger('5')"/> This is the proposal for how to represent a typed atomic value. This is pretty obscure to my novice eyes. Reading this I wouldn't guess off hand that this means "Atomic value, type xs:positiveInteger, text value '5'". Well, I think it's merit is that it's familiar
syntax and semantics for anyone who knows XSLT 2.0 or wants to go and read the
spec. For many purposes, however, a more convenient syntax would be
<atomicValue value="5"
type="xs:positiveInteger"/>.
That then leads me to the final question. Suppose we transform this serialized form "almost an xslt" format, into "real xslt" format, then run a real XSLT 2.0 parser on it. How to get the resulting values out ? Please bear with me as I'm very much a novice at XSLT ... maybe the answer is "obvious". XSLT 2.0 claims that the result of an XSLT transformation can be a 'set of result trees'. Thats an XDM sequence . (???) No: XQuery can produce any XDM sequence as output (well,
almost any - it can't for example generate unparsed entities); but XSLT can only
produce a set of document nodes. You can write an xsl:function to produce any
XDM sequence as its result, but you would need a processor-specific way of
invoking the function and capturing its result in the external
environment.
Incidentally, I was reminded of this project in some work with
a client yesterday. They are running MarkLogic queries and feeding the result
into Saxon, currently via lexical XML (it has to be serialized because it's on a
different machine). In this kind of scenario it would be nice to transfer a
typed document, but we really don't want a five-fold increase in document size
over the lexical XML. Size does matter.
Regards, |