W3C home > Mailing lists > Public > public-qt-comments@w3.org > September 2009

[Bug 7239] [XQTS] New test for typed value of potentially namespace sensitive XDM nodes when copied with different in scope namespaces..

From: <bugzilla@wiggum.w3.org>
Date: Tue, 22 Sep 2009 20:11:21 +0000
To: public-qt-comments@w3.org
Message-Id: <E1MqBhp-0003H6-PO@wiggum.w3.org>
http://www.w3.org/Bugs/Public/show_bug.cgi?id=7239





--- Comment #3 from Michael Kay <mike@saxonica.com>  2009-09-22 20:11:21 ---
(ACTION A-407-04)

Please ignore my previous comments. I don't think I studied the example
carefully enough. I now see what you are getting at.

The thinking behind XQTY0086 was to ensure that when you copy
namespace-sensitive content, you are obliged to retain all the in-scope
namespaces, to ensure that the typed value remains valid. But your example
demonstrates that we don't prevent the node acquiring new in-scope namespaces
as a result of the copy, and although the new namespaces cannot make the value
invalid, they can cause revalidation to produce a different typed value.
Exactly the same problems apply to the equivalent XSLT error XTTE0950.

So, yes, I think it's a spec problem. I don't think it's realistic to prevent
the fragment acquiring new in-scope namespaces on a copy, so I think we have to
come up with a rule that explains what happens.

We currently say in Data Model 3.3.1.3 "However, implementations are allowed
some flexibility in how these properties are stored. An implementation may
choose to store the string-value only and derive the typed-value from it, or to
store the typed-value only and derive the string-value from it, or to store
both the string-value and the typed-value."

We already know of cases where there are observable differences between
products based on which of these strategies they adopt. Immediately after the
quoted paragraph we give the example 

<offset xsi:type="xs:integer">0030</offset> 

and point out that the string value of this element may be returned as either
"30" or "0030". 

We also have a rule in the DM spec that says the relationship between the
string value and the typed value must be "consistent with schema validation":
"The relationship between the type-name, typed-value, and string-value of an
element|attribute node is consistent with XML Schema validation". This implies
that the typed value must not be different from the value you would get if you
revalidated. However, this rule fails to take into account the fact that the
relationship between string value and typed value is also a function of the
namespace context.

I think there are two options.

OPTION A. We respect the principle "implementations are allowed some
flexibility in how these properties are stored", and recognize that this has
the consequence that in cases where validation is namespace-sensitive, this may
weaken the principle that the typed value is always the same as you would get
by revalidating the string value against the type-name (also leading to
differences between products in edge cases, though less severe than the
differences we already tolerate).

OPTION B. We respect the principle "the relationship between the string value
and the typed value is consistent with schema validation", with the consequence
that where the typed value is namespace sensitive, implementations may need to
recompute the typed value when data is copied and the namespace context
changes.

Because this case is likely to be so rare in practice, my recommendation is to
choose option A, which probably means that no implementation needs to change to
accommodate this case. I think we can achieve this by adding a description of
this case to section 3.3.1.3 in DM, and perhaps a caveat where we describe the
typed value of element and attribute nodes as being "consistent with schema
validation".


-- 
Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.
Received on Tuesday, 22 September 2009 20:11:30 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 15:45:40 UTC