Home. 
.

transparent

transparent

transparent

Altova Mailing List Archives


Re: XML Schema spec: Attribute Wildcard Intersection

From: richard@------.--.--.-- (------- -----)
To: NULL
Date: 5/2/2005 10:33:00 PM
In article <d566bp$2rv4$1@n...>,
Alain Frisch <frisch@c...> wrote:

>3 If either O1 or O2 is a pair of not and a value (a namespace name or 
>·absent·) and the other is a set of (namespace names or ·absent·), then 
>that set, minus the negated value if it was in the set, minus ·absent· if 
>it was in the set, must be the value.

>I don't understand the rationale behind "minus ·absent· if it was in the 
>set". This means that ·absent· is removed whenever it appears in the set. 
>It would be natural to remove it iff the second component of the "not" 
>pair is ·absent·. 

>Can someone explain the rationale behind the spec ?

The case described is the intersection of ##other and and set of
namespaces.  In this context, "absent" means "no-namespace".

When the target namespace is absent, ##other means any non-absent
namespace.  When the target namespace is not absent, ##other means any
*non-absent* namespace other than the target namespace.  I think the
idea behind this is that ##other is intended to allow extensibility by
having attributes from other namespaces, not by having attributes in
no namespace.

So in the latter case, the intersection should exclude both the target
namespace and absent.

Now for some reason that is not clear to me [*], the namespace
constraint ##other is not represented as a pair of "not" and (a set of
the target namespace and absent), but merely as a pair of "not" and
the target namespace.  So to make the intersection give the right
answer, the spec has to give the peculiar definition quoted.
Similarly, it has to give a peculiar definition for "Wildcard allows
Namespace Name" a few paragraphs earlier.

[*] It's probably one of those "historical" reasons.

-- Richard


transparent
Print
Mail
Like It
Disclaimer
.

These Archives are provided for informational purposes only and have been generated directly from the Altova mailing list archive system and are comprised of the lists set forth on www.altova.com/list/index.html. Therefore, Altova does not warrant or guarantee the accuracy, reliability, completeness, usefulness, non-infringement of intellectual property rights, or quality of any content on the Altova Mailing List Archive(s), regardless of who originates that content. You expressly understand and agree that you bear all risks associated with using or relying on that content. Altova will not be liable or responsible in any way for any content posted including, but not limited to, any errors or omissions in content, or for any losses or damage of any kind incurred as a result of the use of or reliance on any content. This disclaimer and limitation on liability is in addition to the disclaimers and limitations contained in the Website Terms of Use and elsewhere on the site.

.
.

transparent

transparent