OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help



   Re: [xml-dev] Type-based design patterns

[ Lists Home | Date Index | Thread Index ]

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

| 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

| 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.

| 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,

- -- 
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.  | 
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: Processed by Mailcrypt 3.5.7 <http://mailcrypt.sourceforge.net/>



News | XML in Industry | Calendar | XML Registry
Marketplace | Resources | MyXML.org | Sponsors | Privacy Statement

Copyright 2001 XML.org. This site is hosted by OASIS