- 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