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

Hi Jonathan,

> As I've said, consider the 'this:person' QName a convenient
> shorthand for a pattern "mother|father" sort of like:
>         <xsl:template match="&this.person;">
>                 ...
>         </xsl:template>
> so, true, one needs to edit the pattern for maintainance sake, but
> similarly one needs to edit the schema.

Yes.  If you use an entity then you have to edit the stylesheet and
the schema; if you have a type-checking mechanism, you only have to
edit the schema.  My point is that as an XSLT application developer, I
could write a stylesheet that people would not have to touch even if
they extended/amended 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).

That's a very interesting point.  If we see any set of nodes taking
part in a pattern that involves a union, we can assume that they are
of the same type, precisely because they are being treated in the same
way by that application.

Personally, I like the idea of explicitly labelling those types, both
so that we can use those labels to make the similarities between the
nodes explicit, and so that we can create type hierarchies which tell
us something about the structure of the domain.  But that's the
knowledge engineer in me, I guess.

> Since I have your attention, rather than
> match="*[xs:type='this:person']" consider something like:
>         match="exslt:typeOf(.,'this:person')"
> as a proper extension of XSLT 1.0 and see that this might be
> implemeneted in a schema language neutral fashion.

Just to make sure I understand what you mean by the above - you're
advocating adding a new node test called exslt:typeOf?

I actually wrote match="*[xs:type('this:person')]". I used an
extension function because they're the least controversial and
dramatic way of extending XPath. Of course, the people designing XPath
2.0 are a lot freer than we are ;)

Anyway, I thought this syntax for xs:type() gelled well with the way
that lang() works in XPath at the moment. Another possibility for the
same kind of extension function would be:

  match="*[xs:type() = 'this:person']"

When I have a few spare moments, I'll have to look at the extension
functions that MSXML4 has implemented and add them (or something like
them) to a new 'XML Schema' module in EXSLT...



Jeni Tennison