- From: Henry S. Thompson <ht@inf.ed.ac.uk>
- Date: Tue, 11 Nov 2008 13:36:12 +0000
- To: "Michael Kay" <mike@saxonica.com>
- Cc: "'Christian Roth'" <roth@visualclick.de>, "'XML Schema Development List'" <xmlschema-dev@w3.org>
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Michael Kay writes:
>> Yes, I would have expected a union in the same way single
>> attribute definitions form a union, since my personal view up
>> to now on "anyAttribute" was that it's just a slightly more
>> generalized "attribute". Obviously, it's not, but treated
>> quite differently. Haven't thought on this long enough, but:
>> are there use cases for namespace intersections?
Yes, when you have negated wildcards (##other), intersection is
typically what you want. Consider a v1 schema designed for
extensibility, which includes a attribute for 'standard'
attributes, and an allowance for extensibility:
<xs:attributeGroup name="standard">
<xs:attribute ref="xml:base"/>
<xs:attribute ref="xml:id"/>
<xs:attribute ref="v1:owner"/>
. . .
<xs:anyAttribute namespace="##other" processContents="lax"/>
</xs:attributeGroup>
Now, in the v2 schema, I want to define a group which adds an
attribute to that group and still allows extension:
<xs:attributeGroup name="standard">
<xs:attributeGroup ref="v1:standard"/>
<xs:attribute ref="v2:status"/>
<xs:anyAttribute namespace="##other" processContents="lax"/>
</xs:attributeGroup>
Intersection is what you want here -- extension attributes are allowed
provided they are qualified with _neither_ v1 _nor_ v2. Union would
be useless, as that would allow _any_ qualification, including v1 or
v2.
I agree the situation is less than ideal, one would really like much
more detailed control over what happens.
ht
- --
Henry S. Thompson, School of Informatics, University of Edinburgh
Half-time member of W3C Team
10 Crichton Street, Edinburgh EH8 9AB, SCOTLAND -- (44) 131 650-4440
Fax: (44) 131 651-1426, e-mail: ht@inf.ed.ac.uk
URL: http://www.ltg.ed.ac.uk/~ht/
[mail really from me _always_ has this .sig -- mail without it is forged spam]
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.6 (GNU/Linux)
iD8DBQFJGYpMkjnJixAXWBoRAoK8AJ9jT/R/2cVei2bTccaMklw7IymHhgCeMRiY
ziFDqoTsszZhrQ869FBzdqY=
=3F5R
-----END PGP SIGNATURE-----
Received on Tuesday, 11 November 2008 13:36:57 UTC