This is the mail archive of the xsl-list@mulberrytech.com mailing list .


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

RE: Future XSLT expansion.


Hi Jon,

[posting about some variable implementation ...]

Didier replies:
Gee Jon, you didn't picked an easy one. What did you do this morning to spot
this black hole in our XSLT universe :-)).

I agree that this is not so obvious to know what is the right
implementation. What is obvious thought is that having the capability to do
what you said is useful.

Let's try to clear that up:

First the XSLT DTD states:
<extract>
<!ELEMENT xsl:variable %template;>
<!ATTLIST xsl:variable
  name %qname; #REQUIRED
  select %expr; #IMPLIED
>

<!ENTITY % template "
 (#PCDATA
  %instructions;
  %result-elements;)*
">

<!ENTITY % instructions "
  %char-instructions;
  | xsl:processing-instruction
  | xsl:comment
  | xsl:element
  | xsl:attribute
">
</extract>

So from the DTD declaration is it clear that the element can contains parsed
character data - which means that the content can be parsed and any markup
to be recognized. It can contain also instructions and result-elements that
are application specific as, for instance, like below:

<!ENTITY % result-elements "
  | fo:inline-sequence
  | fo:block
">

So far so good, now when we read the section about the xsl:variable we get:
<extract>
"Variables introduce an additional data-type into the expression language.
This additional data type is called result tree fragment. A variable may be
bound to a result tree fragment instead of one of the four basic XPath
data-types (string, number, boolean, node-set). A result tree fragment
represents a fragment of the result tree. A result tree fragment is treated
equivalently to a node-set that contains just a single root node"
</extract>

And several examples and explanations are about the select construct witch
obviously allows to return a tree fragment. At first, I was puzzled if we
can or not have structured content as content of the variable element but if
I read it well, this paragraph states that yes:

<extract>
If the variable-binding element does not have a select attribute and has
non-empty content (i.e. the variable-binding element has one or more child
nodes), then the content of the variable-binding element specifies the
value. The content of the variable-binding element is a template, which is
instantiated to give the value of the variable. The value is a result tree
fragment equivalent to a node-set containing just a single root node having
as children the sequence of nodes produced by instantiating the template.
The base URI of the nodes in the result tree fragment is the base URI of the
variable-binding element.
</extract>

So, always if I understood the text well (we are never sure with specs :-))
and if my lawyer says that we have jurisprudence here :-)) then, it seems
that yes a variable element can contain structured content and not only
strings.

Thanks Jon for having raised the issue, you give us an opportunity to get
some light on this and give a chance to implementers to prepare a new
release...to add this hidden feature ;-)

But I may be wrong and it is better if somebody else would check and double
check the specs to to bring some more light. So that we can update our FAQ
and conformance tests.

Cheers
Didier PH Martin
----------------------------------------------
Email: martind@netfolder.com
Conferences: Web Chicago(http://www.mfweb.com)
             XML Europe (http://www.gca.org)
Book: XML Professional (http://www.wrox.com)
column: Style Matters (http://www.xml.com)
Products: http://www.netfolder.com





 XSL-List info and archive:  http://www.mulberrytech.com/xsl/xsl-list

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]