Re: [xsl] Can XPath / XSLT be aware of XML Schema content models grouping i nformation ?

Subject: Re: [xsl] Can XPath / XSLT be aware of XML Schema content models grouping i nformation ?
From: Jeni Tennison <jeni@xxxxxxxxxxxxxxxx>
Date: Tue, 13 Nov 2001 22:27:05 +0000
Hi Jerome,

> The source and result documents describe both a map containing a
> list of points with optional label. However the source document
> "flatten" the list.
> So, without being able to do a <xslt:for-each> on the sequence, the
> conversion seems to me already quite complex if you consider the
> potential abscence of the Label element in the sequence.

What you're describing is a classic flat-to-hierarchy grouping
problem, and the usual XSLT solution (at the moment) would be to apply
templates to all the X elements (since you "know" that they are the
first in the list) and within the template for each generate the Point
element with the content being a copy of the X element and any Y or
Label elements that belong to it.

Support for this kind of grouping problem is down on the list of
requirements for XSLT 2.0, so there should be some nice way of doing
this eventually. But I think saying that the grouping specification is
something that you can get from the *schema* is very interesting...

In a way, here you're treating the model group in the schema as a kind
of regular expression for the XML structure that you have, and using
the result of the match on the regular expression to create the
structure that you want. I think that's a really powerful way to
describe this kind of grouping (though it would probably be more
powerful if the "regular expression" was specified using RELAX NG,
which is suited to that kind of thing, rather than XML Schema). You
could also use it nicely with groups based on position (view a
sequence of items as a sequence of pairs of items, for example). I
wonder if the WG have considered something like it...

>> The more information is available in the data model, the more it's
>> tied to a particular schema language.
> So, in your mind where is the right balance ? 
> Maybe a neutral / generic schema infoset in the XPath data model ?

It's a really difficult question to answer. I think that practically
and morally(!) XPath/XSLT should support people using different kinds
of schema languages, DTDs, or no schema language if they don't need

But the only thing you can really guarantee about a (grammar-based)
schema is that it will contain things that can be considered the
declarations/definitions/descriptions of the elements and attributes
in the source document.

One possibility that would enable you to get hold of whatever
information you need, whatever the schema language, is to get hold the
element/attribute declarations as element nodes within the schema node
tree (you could do a simple mapping from DTDs syntax to XML syntax to
get DTD information). You could then use standard location paths to
accessing the further details.

Given that, it should be possible for people (users,
schema-spec-writers or implementers) to define
schema-language-specific extension functions that access extra
information as required from that element declaration. So I think all
the data model needs to do on the structure side is include a link to
the element node for an element/attribute declaration in the
schema/DTD from an element/attribute node in the instance/source

On top of that, it seems that the most useful piece of information
from a schema is the data type of a text-only element or attribute.
The range of possible data types differs across schema languages, and
indeed across schemas if you count user-defined simple types in XML
Schema. However you still want to be able to do useful things like add
a date and a duration easily, and for that XPath has to have some
understanding of and hence limit on the data types that it allows. I
think the set of XML Schema primitive data types is pretty good, and
that either other types could be coerced to them or we'll make do with
strings as we have in XPath 1.0. So I think it would also handy to be
able to get quick access from an element or attribute to the name of
its type, and to its value as the appropriate XPath-supported data

... Well, those are some ideas anyway - I'm not sure whether they tie
together or would stand up to close scrutiny. I'm almost certain that
it isn't the way that XPath will be developed :)



Jeni Tennison

 XSL-List info and archive:

Current Thread