Lists Home |
Date Index |
Jeff Lowery <email@example.com> writes:
> 1) Adding new value members to the value space of a type can't be any good
> under any circumstances. It's possible to think up some use for such a
> feature, but it would no doubt be better implemented using one of the other
If you mean simple type == datatype, then not only is it bad, it's not
possible using W3C XML Schema. There is no derivation by extension
from simple types.
> 2) "Content space" refers to all specified child elements and attributes in
> a type definition (there's probably a term for this already, but I've a
> peasouper of mental fog today). The big fork in the road here is whether the
> model group of elements is sequenced or not.
> 2a) If it's unsequenced, then addition (via extension) of new elements that
> were restricted in occurrence in the supertype would likely break the bank.
> For sequenced content, it seems less of a worry, taking Paul's XSLT example
> as a worse case. Frankly, if you're not blocking extension of sequenced
> content, you have to accept what you're given. Does that take too much
> discipline? I'm the wrong person to ask, but a schema editor might support
> an autoblocking configuration for complextype extension.
Note here that W3C XML Schema extension is _always_ sequenced, in the
sense that any member of a type defined by extension _must_ contain a
member of the base type as a prefix.
This property does _not_ hold for substitution groups, where
type-based patterns rather than element-based ones are the only safe
way to go.
Henry S. Thompson, HCRC Language Technology Group, University of Edinburgh
W3C Fellow 1999--2002, part-time member of W3C Team
2 Buccleuch Place, Edinburgh EH8 9LW, SCOTLAND -- (44) 131 650-4440
Fax: (44) 131 650-4587, e-mail: firstname.lastname@example.org
[mail really from me _always_ has this .sig -- mail without it is forged spam]