Re: Identity-constraints, attributes and lax/skip wildcards

Hi,

On Thu, 2005-04-28 at 09:04 +0100, Henry S. Thompson wrote:
> Kasimier Buchcik writes:
> 
> > It might be that I found an answer for my question:
> >
> > In "3.2.5 Attribute Declaration Information Set Contributions" we
> > have the following:
> >
> > "If the attribute information item was not ·strictly assessed·, then
> > instead of the values specified above, 

I wonder what is the sense of this statement at all: since
the type definition must be available and the value must be valid, as
demanded by the prolog to this section, the _only_ way I see for the
attribute _not_ to be strictly assessed here, is to violate § 4 of
"Attribute Locally Valid". Which leads to the question why we
should change the [schema normalized value] and [type definition] just
because of violation of the fixed value constraint. Or did I miss
something?

> > 1 The item's [schema normalized value] property has the ·initial value·
> >   of the item as its value;
> > 2 The [type definition] and [member type definition] properties, or
> >   their alternatives, are based on the ·simple ur-type definition·."
> 
> You may be right -- I think in implementing XSV I took the parallel
> with elements seriously, and interpreted the prolog to this whole
> constraint, namely Schema Information Set Contribution: Attribute
> Validated by Type [1], which says at the beginning
> 
>  "If clause 3 of Attribute Locally Valid (3.2.4) applies with respect
>   to an attribute information item, in the post-schema-validation
>   infoset the attribute information item has a property:"
> 
> together with the element case to mean that when a 'skip' wildcard was
> involved there should be _no_ [type definition].

Yes, right. The prolog wants a type to be available, plus the value
to be valid with respect to this type. So, since during assessment
_no_ type was identified, this clause cannot apply; further, "The [type
definition] and [member type definition] properties, or their
alternatives, are based on the ·simple ur-type definition·" cannot apply
as well. There's neither a fallback mechanism to use the
simple ur-type for "laxly" validated attributes, since attribute
cannot be "laxly" assessed, nor there's a way for the IDCs to use
a PSVI-provided simple ur-type; if IDCs should use the PSVI at all,
which I still don't know.

> I think that's a bug in the spec, which should be corrected if I'm
> right, or clarified if I'm wrong.

As I currently read the spec, evaluation of IDCs to attributes is not
allowed, if such attributes fall under "skip" wildcards or "lax"
wildcards with no existent attribute declaration.
So the behaviour of XSV, to refuse to use such attributes as IDC field
targets seems correct. Xerces-J 2.6.2 and MSXML 4.0 seem not to work
here correctly.

Can the WG confirm this, or the opposite?

Regards,

Kasimier

Received on Thursday, 28 April 2005 09:28:51 UTC