[
Lists Home |
Date Index |
Thread Index
]
Hi Norm,
> | I guess that substitution groups give you a bit more of a
> | *classification* semantic. It depends on the model group, of course.
> | Model groups that are choices between several elements are much like
> | substitution groups. Model groups that cover the entirety of an
> | element's content when they're used are more like types. And then
> | there are some model groups that don't fall into either camp, of
> | course.
>
> Right. I have parameter entities in all those categories :-) And
> given that an element can only be in one substitution group, I'm not
> sure that they're worth a lot of effort.
You may be right (though it'd be a shame since I get the impression
that substitution groups were created for precisely the kind of
"inline" or "block" groups -- "usage groups", as Debbie put it -- that
document-oriented languages use). You're probably aware that
substitution groups can have multiple levels, so you can get elements
to belong to many of them simultaneously as long as they form a
hierarchy. But I agree that doesn't meet the general requirement.
> | I feel I should back off from W3C XML Schema a bit though, and talk in
> | the more general case. In the more general case, we just want to be
>
> Yep. In the more general case, I have to make DocBook schema in
> RELAX NG syntax, DTD syntax, and W3C XML Schema syntax. And I'd like
> to add some Schematron as well for checking some classes of
> restrictions.
>
> I have this vision of generating all three (or four) designs from a
> single bit of source. I'm about half way there, I think. But this
> approach naturally has a single conceptual design and so it's not
> clear that I'm going to be able to use the best/most appropriate
> features of all the schema languages with equal ease. Maybe the
> whole project will collapse. Too early to tell.
:)
The mismatch in approach between RELAX NG and W3C XML Schema is the
most problematic aspect, I imagine. I don't know how far James Clark's
got with Trang's RNG->XSD converter, and if you do XSD=>RNG conversion
then you don't get all of RELAX NG's nice co-occurrence constraint
support. I'd be really interested to see what you come up with.
> | I guess that what this means is that I think the *type* of an element,
> | in XPath Data Model terms, should be a list of labels, gathered from
> | both its type and substitution group (in W3C XML Schema terms).
> | Unfortunately, types and substitution groups have different name
> | spaces so there'd be clashes if it was done simplistically, but you
> | get the general idea.
>
> Yes. I've long thought that if we're going to do types in the data
> model at all, they should just be names (QNames, URI, NUNs,
> whatever). I'm happy to leave anonymous types entirely inaccessible
> in the data model (you made them anonymous, don't complain to me
> that they don't have names).
That's pretty much where we are at the moment, isn't it? Types are in
the data model as QNames rather than as "type nodes" or something?
> If we said that the only interface between the schema processor and
> the type system was a set of names, we could support multiple schema
> languages more easily, I think. And a natural extension would be to
> say that some nodes can have more than one type.
Agreed. I also wonder whether it could be a way to prevent XPath from
having to have "in-scope schema definitions" in its static context
(trying to decouple from W3C XML Schema here). Rather than saying an
element <size> has a type of "hatSize" and then going to the in-scope
schema definitions to work out that "hatSize" is an xs:integer, which
is itself an xs:decimal, the data model could just record that the
types of the element <size> are "hatSize", "xs:integer" and
"xs:decimal". Checking whether something is an instance of a type
would just be a matter of checking the list.
I'm not sure whether that would work -- in particular I'm not sure
about the casting *down* the hierarchy, but I think it would be worth
investigating. It's always disturbed me slightly that the data model
for XPath 2.0 can't be used to represent some of the information used
in the static context of XPath 2.0.
> | really messy having to split up your stylesheets like that. I agree
> | that we need an <xsl:next-match> instead.
>
> Worse than the mess, it just about destroys the ability to customize
> that stylesheet by importing it somewhere else.
True. You have to do a lot of work to provide "call backs" to get
around that (moded templates and all that).
Cheers,
Jeni
---
Jeni Tennison
http://www.jenitennison.com/
|
