Cart
|
[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] Re: Type-based design patterns
 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/ 
|
PURCHASE STYLUS STUDIO ONLINE TODAY!Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced! 
Download The World's Best XML IDE!Accelerate XML development with our award-winning XML IDE - Download a free trial today! Subscribe in XML format
|
|||||||||
