Hi,
how to handle the following scenario?
- an attribute was validated against a "skip" wildcard
- R an attribute was validated against a "lax" wildcard and no
corresponding declaration was existent
- an IDC field evaluated to such an attribute
Validation rule "Identity-constraint Satisfied" says:
"3 For each node in the target node set all of the {fields}, with that
node as the context node, evaluate to either an empty node-set or a
node-set with exactly one member, which must have a simple type"
Should such an attribute have a simple type? Should we fall back
to "anySimpleType" here - similar to elements, where we fall back to
"anyType" if the wildcard was "lax"?
Example:
Schema:
<xsd:schema xmlns:xsd="">
<xsd:element name="foo">
<xsd:complexType>
<xsd:anyAttribute namespace="##any" processContents="skip"/>
</xsd:complexType>
<xsd:key name="aKey">
<xsd:selector xpath="."/>
<xsd:field xpath="@bars"/>
</xsd:key>
</xsd:element>
</xsd:schema
Instance:
<foo bar="abc"/>
XSV 2.8 reports:
"missing one or more fields [<XSV.util.xpath.XPath instance at
0x0131A120>] from key {None}aKey
while Xerces-J 2.6.2 and MSXML 4.0 both eat it.
Regards,
Kasimier

Hi,

Tue, 2005-04-26 at 19:36 +0200, Kasimier Buchcik wrote:
Hi,

how to handle the following scenario?
- an attribute was validated against a "skip" wildcard
- R an attribute was validated against a "lax" wildcard and no
corresponding declaration was existent
- an IDC field evaluated to such an attribute

Validation rule "Identity-constraint Satisfied" says:

"3 For each node in the target node set all of the {fields}, with that
node as the context node, evaluate to either an empty node-set or a
node-set with exactly one member, which must have a simple type"

Should such an attribute have a simple type? Should we fall back
to "anySimpleType" here - similar to elements, where we fall back to
"anyType" if the wildcard was "lax"?

Example:

Schema:
<xsd:schema xmlns:xsd="">
<xsd:element name="foo">
<xsd:complexType>
<xsd:anyAttribute namespace="##any" processContents="skip"/>
</xsd:complexType>
<xsd:key name="aKey">
<xsd:selector xpath="."/>
<xsd:field xpath="@bars"/>

Correction: this should be <xsd:field xpath="@bar"/>

</xsd:key>
</xsd:element>
</xsd:schema

Instance:
<foo bar="abc"/>

XSV 2.8 reports:

"missing one or more fields [<XSV.util.xpath.XPath instance at
0x0131A120>] from key {None}aKey

while Xerces-J 2.6.2 and MSXML 4.0 both eat it.

Kasimier

Hi,

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,
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."

The question - now more clearly definable for me - if an attribute,
which was not strictly assessed, can be a target for IDCs fields,
could be answered with yes, assuming IDCs use the PSVI when evaluating.

Is this correct? I dearly need some advice here, even if it reveals
to be an "implementation dependant" thingy.

Regards,

Kasimier

Tue, 2005-04-26 at 19:41 +0200, Kasimier Buchcik wrote:
Hi,

Tue, 2005-04-26 at 19:36 +0200, Kasimier Buchcik wrote:
Hi,

how to handle the following scenario?
- an attribute was validated against a "skip" wildcard
- R an attribute was validated against a "lax" wildcard and no
corresponding declaration was existent
- an IDC field evaluated to such an attribute

Validation rule "Identity-constraint Satisfied" says:

"3 For each node in the target node set all of the {fields}, with that
node as the context node, evaluate to either an empty node-set or a
node-set with exactly one member, which must have a simple type"

Should such an attribute have a simple type? Should we fall back
to "anySimpleType" here - similar to elements, where we fall back to
"anyType" if the wildcard was "lax"?

Example:

Schema:
<xsd:schema xmlns:xsd="">
<xsd:element name="foo">
<xsd:complexType>
<xsd:anyAttribute namespace="##any" processContents="skip"/>
</xsd:complexType>
<xsd:key name="aKey">
<xsd:selector xpath="."/>
<xsd:field xpath="@bars"/>

Correction: this should be <xsd:field xpath="@bar"/>

</xsd:key>
</xsd:element>
</xsd:schema

Instance:
<foo bar="abc"/>

XSV 2.8 reports:

"missing one or more fields [<XSV.util.xpath.XPath instance at
0x0131A120>] from key {None}aKey

while Xerces-J 2.6.2 and MSXML 4.0 both eat it.

Kasimier

Hi,

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. 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

Thu, 2005-04-28 at 11:28 +0200, Kasimier Buchcik wrote:
Hi,

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. 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

Thu, 2005-04-28 at 10:34 +0100, Henry S. Thompson wrote:
Kasimier Buchcik writes:

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.

Disagree slightly -- the latter case (lax but not decl found) is
precisely when the fallback to anySimpleType makes sense.

Yes, and it would reflect the behaviour of elements; but there's
no fallback defines as for elements:

"If the item cannot be strictly assessed, because neither clause 1.1
nor clause 1.2 above are satisfied, [Definition:] an element
information item's schema validity may be laxly assessed if its
context-determined declaration is not skip by validating with
respect to the ur-type definition as per Element Locally Valid (Type)
(3.3.4)."

As by now, lax assessment is not allowed by the spec.

Kasimier