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

On Thu, 2005-04-28 at 11:28 +0200, Kasimier Buchcik wrote:
> 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, 

Hmm, after reading the section again, I seem to be confused: does the
above spec. piece apply _if_ the prolog applies or if the prolog does
_not_ apply, thus being a fallback mechanism?

> 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:35:37 UTC