- From: <bugzilla@wiggum.w3.org>
- Date: Tue, 22 Sep 2009 20:11:21 +0000
- To: public-qt-comments@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