[
Lists Home |
Date Index |
Thread Index
]
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
/ Jeni Tennison <jeni@jenitennison.com> was heard to say:
| 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).
Yes. I'm at least partly responsible as I was on the WG at the time.
Later on, when model groups were added to the list of things that
redefine could change, substitution groups became less necessary, I
think.
| 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.
Right. That's why it's not hopeless, just probably difficult :-)
| support. I'd be really interested to see what you come up with.
You and me both :-). Some day. I need a paper for, uhm, Extreme 2003,
right? :-)
|> 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?
Yes, but I have this uneasy feeling that there's still too much
implicit dependence on WXS under the surface of the whole suite of
documents.
| 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.
Yes. That's the start of a generalized solution to the inheritance problems.
But
| 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
that's the tough nut to crack. Technically possible, I think, if the
majority of people on two large working groups can be convinced that
it's worth doing.
|> | 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).
Right. And that only works if you planned ahead.
Be seeing you,
norm
- --
Norman.Walsh@Sun.COM | The human race consists of the dangerously
XML Standards Architect | insane and such as are not.--Mark Twain
Sun Microsystems, Inc. |
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: Processed by Mailcrypt 3.5.7 <http://mailcrypt.sourceforge.net/>
iD8DBQE9nDtQOyltUcwYWjsRAr4DAJsHxh16AlfoR5Dq3jKV829KBg1nCACgj/G6
jMUHNrVaCsxUW5V7QPnI/Is=
=wEN5
-----END PGP SIGNATURE-----
|
