[
Lists Home |
Date Index |
Thread Index
]
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
/ Jeni Tennison <jeni@jenitennison.com> was heard to say:
| 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.
| 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.
| 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).
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.
| (Tch, local-name()?!? You mean self::orderedlist, don't you? ;)
Yes, of course I do. It's not what I wrote, but it's what I meant :-)
| I agree. Currently you have to do this by importing a stylesheet with
| the templates matching individual list types and do
| <xsl:apply-imports>. I've done this recently in order to add a linking
| semantic to (practically) all the elements in a document, and it's
What markup did you...no, that's another thread. Nevermind :-)
| 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.
| That would mean making type-based matching have the highest priority
| in templates, which kinda feels a bit weird (isn't matching on type
| *more* general than matching by name?) but I don't think there's much
| we can do about that without turning template matching in XSLT
| completely upside down.
Good point(s).
Be seeing you,
norm
- --
Norman.Walsh@Sun.COM | All the good maxims already exist in the
XML Standards Architect | world; we just fail to apply them.--Pascal
Sun Microsystems, Inc. |
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: Processed by Mailcrypt 3.5.7 <http://mailcrypt.sourceforge.net/>
iD8DBQE9nClXOyltUcwYWjsRAh20AJ9Jpn4OUH/FNO1k07F9+5iXRvIOAgCgkDm6
1doNoEDQFeQjy0uIjBAcM4I=
=gXFo
-----END PGP SIGNATURE-----
|
