OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

xslt-conformance message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: RE: [xslt-conformance] Introduction and plea for advice



[Note: you can just reply to xslt-conformance@lists.oasis-open.org, since I'm on that list.]

>A related question is "If you knew the three vocabularies you needed to transform to, how would you go about evaluating different proposed schemas inside your own dialect." This knowlege makes the question different then the generic be ready to transdorm to anything...

That's true, and I have been working on some troublesome XML structures. I may be able to report some specific experiences later this year. A typical problem I encounter is when I am transforming a specific sub-tree and some value is essentially a cross-reference that needs to be looked up in another tree. If the data can't be right there in the sub-tree, then it should be in a "side tree" as high up in the whole document as possible. For example...
Worst case - given the $ItemID, look it up on the Part list for this Page (and I don't know how deep down I am, or how deep the Part list is):
select="ancestor::Page[1]//Part[@ID=$ItemID]/Text"
Not as bad case - given the $ItemID, look it up on the Part list for this Page (which is my grandparent node, and the Part list is its child):
select="../../Part[@ID=$ItemID]/Text"
Better - given the $ItemID, look it up on the universal Part list:
select="/Part[@ID=$ItemID]/Text"
so you can evaluate the design (schema) of the vocabulary by looking at how bad the XPath expressions will have to be for the three transformations. For the above case, notice the potential to use xsl:key.

You want important properties of the data to be findable by evaluating a single expression, as opposed to having to set up a recursive search loop. In the above case, this means that I tested the string equality of @ID and $ItemID, rather than having to execute some other search/match process.

Another thing to think about is some of the xsl:for-each loops that might be needed in the three transformations.

Once your XML vocabulary escapes into the wild, others will probably write stylesheets beyond the three you anticipate. I suspect that if you have a good range of possibilities within the three, you will have accommodated many other needs.
.................David Marston
(speaking for himself, not the TC)



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]