Re: [xsl] Theoretical question

Subject: Re: [xsl] Theoretical question
From: Mike Brown <mike@xxxxxxxx>
Date: Tue, 2 Jan 2001 15:44:34 -0700 (MST)
Handren Mokri wrote:
> 1- Is XSL protocol independed?

Yes, it is protocol-independent.

XSLT has its own processing model; in order to process an XSLT document
you need a dedicated XSLT processing engine (XT, Saxon, MSXML, etc)

> 2- Reference from one element to any other element in the resided document
> or outside of it. I mean, if IDREF(s)
> supports in XSL so you can refer to some element from a certain element,
> provided that the IDREF is defined in the DTD file?

XSLT supports ID/IDREF attribute types via XPath functions. However,
because ID/IDREF attribute types are rather limited, XSLT offers a more
powerful solution called keys. Keys establish a relationship between nodes
that pass a certain test (string-value equivalency) and some other nodes
that are usually found using a relative path from the matching nodes. Keys
can be used in any source tree, but only in one tree at a time.

You do have access to other source trees by using the document() function,
which is specific to XSLT.

> 3- Structural preservation: How treats an input xml document by xsl.

XSLT treats the input document as a node tree that follows the XPath
model. This model is similar to that implied by the DOM, but it does have
some differences (mainly related to attribute nodes).

> XSL is a tree -to- tree query and transformation language, but, is it
> as an ordered -or unordered tree, both the input and output xml document
> treats by XSL?

If I understand the question, ordered. The input document(s) imply source
trees that follow the XPath data model, which prescribes ordering for most
types of nodes (but not namespace nodes or attribute nodes).

With XSLT you create a new tree, the result tree. This tree also follows
the XPath data model, with some minor additions for certain XSLT specific
situations (disable-output-escaping attributes, for example). The parts of
the tree that are ordered will be in whatever order your stylesheet said
to create them in.

> Are node ID remains the same while they pareses by processors?

If you are talking about ID-type attributes on elements, they are not
treated specially, except that extra access is given to them via certain
XPath functions.

If you are talking about the internal ID string generated for every node
(of any type) in a source tree, this is specific to XSLT processors and
may vary from run to run. You generally only use these IDs to test that
the same node exists in 2 different sets; the ID itself doesn't matter.

> Dose XSL preserve the same documental structure for the input XML document
> and maintain the same order or structure even in the output file?

If you are doing an identity transform, sure, but I think your question is
exactly why the word 'transformation' is a misnomer when applied to
XSLT. XSLT is about creating a node tree. During the creation process you
have access to 1 or more node trees that were typically derived from input
XML documents. How you go about creating the tree is your own business; it
does not have to have any relationship to the source tree(s) at all. At
the end of the process, some kind of serialized output may be derived from
your result tree automatically.

> 4- Universal and existential quantifiers "If one or all nodes in a certain
> collection fulfil some condition, like exist in SQL": dose they supports by
> XSL?.

Yes, within an XPath expression you can use predicates:

   /path/to/somenodes[ foo ]

...will evaluate to only those somenodes for which 'foo' is true.

   document('otherdoc.xml')/otherdoc/stuff[ . = 'hello' ]

...will be 'stuff' elements that have a string-value of 'hello'
   and that are children of 'otherdoc' elements
   which, in turn, are children of the root node in the tree
    derived from otherdoc.xml

> 5- Dose XSL has support for infinite or finite definition, that is to say,
> if cycle may appear in the XSL structure or not?.

You can define whatever you want, but you cannot reference or process
something that has an infinite definition. The XSLT processor will run out
of memory. For example, you can have this in your stylesheet:

<xsl:variable name="infinite_result_tree_fragment">
  <xsl:call-template name="add_to_fragment"/>


<xsl:template name="add_to_fragment">
   <data>hello world</data>
   <xsl:call-template name="add_to_fragment"/>

...but if you ever get to a point during processing where you process the
xsl:variable assignment, you will go into infinite recursion.

So the answer to your question is no.

> 6- What about the Null values, how xsl works or behaves in relation to it?

The data types in XPath are: number, string, boolean, node-set

The data type added by XSLT 1.0 is: result tree fragment (it is a
node-set in a different context)

number: can be an IEEE 754 number, but not null.
string: can be an empty string, but not null.
boolean: can only be true or false, not null.
node-set: can be empty (no nodes in the set), but not null.
result tree fragment: can be empty (no nodes in the set), but not null.

So there is no concept of "null" per se.
You either have an object of one of those types, or you don't.
It is an error if you reference an object that is not defined.

This will not work, if foo hasn't been defined...

<xsl:if test="not($foo)">

But this will...

<xsl:variable name="foo" select="''"/> <!-- empty string -->
<xsl:if test="not($foo)">
The test will be true if foo is an empty string, empty node-set, number 0,
or boolean false.

   - Mike
Mike J. Brown, software engineer at            My XML/XSL resources: in Denver, Colorado, USA    

 XSL-List info and archive:

Current Thread