XML Schema spec: Attribute Wildcard Intersection

[Alain Frisch]

Hello,

The following rule in the XML Schema spec, section "Schema Component
Constraint: Attribute Wildcard Intersection" seems strange to me:

=============== =============== =========
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 ?

-- Alain Frisch

[Richard Tobin]

Re: XML Schema spec: Attribute Wildcard Intersection

In article <d566bp$2rv4$1@ nef.ens.fr>,
Alain Frisch <frisch@clipper .ens.fr> wrote:
[color=blue]
>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.[/color]
[color=blue]
>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·.[/color]
[color=blue]
>Can someone explain the rationale behind the spec ?[/color]

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

[Alain Frisch]

Re: XML Schema spec: Attribute Wildcard Intersection

Richard Tobin, dans le message (comp.text.xml: 68011), a écrit :[color=blue]
> 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.[/color]

Many thanks, I missed that. It makes perfect sense, now. I was also
wondering about rule 6, but it is now clear as well.

I have another question. Rule 5 is:

=============== =============== ===============
If the two are negations of different namespace names, then the
intersection is not expressible.
=============== =============== ===============

Can this actually happen in a valid XML Schema document? Does the spec
make it impossible with another condition somewhere else? Otherwise, how
is the processor supposed to handle this case?


-- Alain

[Richard Tobin]

Re: XML Schema spec: Attribute Wildcard Intersection

In article <d575lm$1c13$1@ nef.ens.fr>,
Alain Frisch <frisch@clipper .ens.fr> wrote:[color=blue]
>I have another question. Rule 5 is:
>
>============== =============== =============== =
>If the two are negations of different namespace names, then the
>intersection is not expressible.
>============== =============== =============== =
>
>Can this actually happen in a valid XML Schema document? Does the spec
>make it impossible with another condition somewhere else? Otherwise, how
>is the processor supposed to handle this case?[/color]

It can happen, if you restrict one ##other wildcard with another
(obviously you must have imported a schema for another namespace to be
able to do this).

I think the processor is supposed to handle it by saying "you can't do
that".

-- Richard