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


Help: OASIS Mailing Lists Help | MarkMail Help

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: Types and Context

Jeni Tennison wrote:

> While I agree, given the example that you gave, surely the point of
> getting datatypes in XSLT/XPath would be most obvious in conditions
> where you have two elements that share the same type, either directly:
>    <xs:element name="mother" type="this:person" />
>    <xs:element name="father" type="this:person" />
> Here, the fact that this:mother and this:father share a type means
> that they can be processed in the same way. In XSLT/XPath currently,
> we would encode that by having them both matched by the same template.
> But it would be more extensible if we had a way of matching *all*
> elements of the this:person type instead:
>   <xsl:template match="*[xs:type('this:person')]">
>      ...
>   </xsl:template>
> New elements of the this:person type that were added to the schema
> would automatically be matched by this template, whereas in the
> current situation I'd have to change the XSLT.

	As I've said, consider the 'this:person' QName a convenient shorthand for a
"mother|father" sort of like:

	<xsl:template match="&this.person;">

so, true, one needs to edit the pattern for maintainance sake, but similarly
one needs to edit the schema. schematron seems pretty powerful to me and is
an example of a schema language that more directly uses XPath patterns to
define 'types' (of course one cannot assign a type a proper QName but that's
a syntactic feature of XML Schema). I suspect that 'Tree Regular
Expressions' will provide the same notion of 'type' as matching a pattern
(i.e. regular expression). What I am saying is that this is a _general_ way
to describe type hierarchies across schema languages and indeed one that our
trusty 'ol XSLT/XPath _1.0_ uses (albeit in a limited form).

Since I have your attention, rather than match="*[xs:type='this:person']"
consider something like:


as a proper extension of XSLT 1.0 and see that this might be implemeneted in
a schema language neutral fashion.