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:variable> ... <xsl:template name="add_to_fragment"> <data>hello world</data> <xsl:call-template name="add_to_fragment"/> </xsl:template> ...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: webb.net in Denver, Colorado, USA http://skew.org/xml/ XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list
Current Thread |
---|
|
<- Previous | Index | Next -> |
---|---|---|
[xsl] Theoretical question, Handren Mokri | Thread | [xsl] for-each loops: arithmetic f, Mazza, Glen |
[xsl] for-each loops: arithmetic f, Mazza, Glen | Date | Re: [xsl] for-each loops: arithmet, Mike Brown |
Month |