Hi,
Can anyone help me sort of (I don't have a running Saxon around):
1) If the element a is declared with, say, the simple nonatomic IDREFS
type as its simpleContent
and I have an instance document with
<a> foo bar baz</a>
and that a element becomes the context node for
<value-of select="."/>
I should get as output the (one) text node with
foo bar baz
right? But really, behind the scenes, it was atomized and re-de-atomized
:), so I assume that
<value-of select="." separator="-ostrich-"/>
should get me
foo-ostrich-bar-ostrich-baz
Is that a complete misunderstanding?
If not, well what about:
<value-of select="./text()" />
or
<value-of select="./text()" separator="-ostrich-"/>
My _understanding_ is that they should both just output
foo bar baz
because text() doesn't atomize, but I am open for any objections.
Another one: XSLT2 will validate even temporary trees, right? But will
that not make a funny difference sometimes?
If the declaration of a was a simpleContent complex type, with an
aoptional attribute x with the default value "goat", then I seem to
recall that an XSD should add that attribute if it is not there.
Does that not mean that
<variable name="v1">
<a xsl:validation="strict">foo bar</a>
</variable>
and
<variable name="v2">
<a>foo bar</a>
</variable>
will behave differently in
<some-instruction select="$one-of-the-above/@x"/>
--- namely the selection finding asn attribute in one case, and nothing
in the other?
Finally
The
document-node(schema-element(rubberduck))
node test is one bastard to analyze (I'm doing static analysis on XSLT):
It tests not one, but tow nodes.
Are there any great dangers in converting it to
document-node()[child::schema-element(rubberduck)]
? A great danger is if the original version, as a pattern, can match
something that the rewritten version cannot.
Thanks for any help
Soren