RE: [xsl] XSLT 2.0, using Schema-aware features

Subject: RE: [xsl] XSLT 2.0, using Schema-aware features
From: "Bill Riegel" <BRiegel@xxxxxxx>
Date: Fri, 12 Jan 2007 11:23:10 -0600
Again, thanks to Mike and David for your time.

I do not like duplicating templates.

So I'm going to play with the schema to see if I can achieve
Feature of

"If you know that in fact there is
effectively one type per element"

Any references to examples or tutorials on this subject would be
appreciated.

Bill Riegel
LandMark Graphics
Phone: 713-839-3388
Fax: 713-839-3051

-----Original Message-----
From: David Carlisle [mailto:davidc@xxxxxxxxx]
Sent: Friday, January 12, 2007 11:05 AM
To: xsl-list@xxxxxxxxxxxxxxxxxxxxxx
Subject: Re: [xsl] XSLT 2.0, using Schema-aware features


Mike will correct me if I'm wrong (I hope) but I think that if you do


  <xsl:template match="foo">


then xslt2 doesn't give any way of telling the system that you intend
_all_ the input to be validated against your schema, so it can't do the
compile time analysis that it can do in the match="element(foo, some
schema type )" case, as you might just throw an unvalidated document
at that template and it's supposed to match.  This, combined with the
fact that you can't use the syntax "element(foo, some schema type ) in a
basic system unless you guard it with a use-when means that you are
rather short of ooptions.

You could use


  <xsl:template
  use-when="system-property('xsl:is-schema-aware')='yes'"
  match="element(foo, some schema type )"

...

 <xsl:template
  use-when="system-property('xsl:is-schema-aware')='no'"
  match="foo"
...

but the problem is that you have to duplicate all the ... code (although
obviously you could factor that into a named template or something.

But my concern here would be that unless you are very careful with the
factoring then effectively what yo uhave is two different
transformations
for two different systems just packaged into one file, and the code
paths in the basic system are so different from that in the schema aware
system, the extra checks that the SA system did while developing the
stylesheet aren't really telling you anything about the templates that
are actually used if the stylesheet is deployed by a basic system.

I should say this is all speculative on my part, as ive only used the
basic system in anger, although i have read the spec a few times by now.

It depends a lot on the schema. If you are making use of the fact that
the schema defines dozens of elements with the same name but different
types, and match on those types, then things are hard to make work on
teh basic processor, as you have to move that type knowledge into the
match pattern from teh schema. If you know that in fact there is
effectively one type per element name, and you are just using the type
matching to get the extra compile checks then it's most likely possible
to automate the production of a basic stylesheet from teh sa one by just
replacing element(foo, some schema type ) by foo with a global change
for example.


David

----------------------------------------------------------------------
This e-mail, including any attached files, may contain confidential and
privileged information for the sole use of the intended recipient.  Any
review, use, distribution, or disclosure by others is strictly prohibited.  If
you are not the intended recipient (or authorized to receive information for
the intended recipient), please contact the sender by reply e-mail and delete
all copies of this message.

Current Thread