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: transform optimization for a schema-constrained domain


Irrespective of whether XSLT processors can perform optimizations with
schema information, I think providing integration of the two could still be
quite useful. There are plenty of instances where a particular use of XML
will involve both the authoring of a schema and an XSLT transform. The
opportunities for disconnects between the two can quite naturally lead to
bugs. Plus, the fact that people using schemas may want to have reusable
logic based on the data type of a node rather than simply an element name is
another reason why I think this may be useful. 

I'm not very experienced with XSLT, yet. However, I think it would be useful
to wed XSLT with schema languages in two respects:

It would very cool to be able to have templates that can match on PSVI info.

It would useful to be able to embed templates within element declarations in
a schema, similar to the way you can annotate a schema with Schematron
assertions. Rather than specifying an XPath to match on, the XPath can be
inferred by the template's context in the schema. This could also ease the
learning curve of XSLT for folks more accustomed to a top-down structured
approach -- folks who tend to struggle with the pattern-based and functional
programming aspects of XSLT.

Beyond that, I'd really like to be able to create data types other than just
result tree fragments within the content of a <variable> tag (given that I
am mainly using XML for application integration, and the rather anemic data
type support of XSLT is rather frustrating at times).

 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]