This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.

Bug 2700 - [XSLT] need to clarify type value after stripping type annotations
Summary: [XSLT] need to clarify type value after stripping type annotations
Status: CLOSED FIXED
Alias: None
Product: XPath / XQuery / XSLT
Classification: Unclassified
Component: XSLT 2.0 (show other bugs)
Version: Candidate Recommendation
Hardware: All All
: P2 normal
Target Milestone: ---
Assignee: Michael Kay
QA Contact: Mailing list for public feedback on specs from XSL and XML Query WGs
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2006-01-11 18:51 UTC by Joanne Tong
Modified: 2006-03-13 10:41 UTC (History)
0 users

See Also:


Attachments

Description Joanne Tong 2006-01-11 18:51:42 UTC
According to section 6.2.4 (Construction from a PSVI) [Data Model], a type-
name and a typed-value are set during construction.  Other properties, such as 
is-id, are set after type-name is available.  If an element is typed 
xs:integer* for example, the typed-value would contain a sequence of 
integers.  According to section 4.3 (Stripping Type Annotations from a Source 
Tree) [XSLT 2.0], if a stylesheet specifies input-type-annotations="strip", 
all type-names are removed and replaced with xs:untyped.  This section does 
not mention how the typed-value would be affected after removing the type-
name, or during which phase is the typed-value determined (whether before or 
after the type-name has been stripped).  In this example, would the typed-
value be a sequence of integers or a string? If type-name was xs:ID before it 
was stripped, would is-id return true or false?
Comment 1 Michael Kay 2006-01-11 20:10:19 UTC
Good point. I tend always to think of the typed value as being a function of the
type name and the string value but you're right that it's not expressed that way
in the data model. Clearly, to maintain consistency, when we change the type
name to untyped we should change the typed value to "what it would have been"
(more thought needed on how to phrase that).

The isID property is a separate issue - we need to make clear whether stripping
type annotations removes this property. We could go either way on this and
retain consistency.
Comment 2 Michael Kay 2006-01-26 18:29:58 UTC
Note from discussion: we decided that when stripping type annotations, the is-id
and is-idref properties should be retained, but the is-nilled property should be
dropped.
Comment 3 Michael Kay 2006-01-27 20:31:13 UTC
Note: we decided that the is-id and is-idref properties should be retained.
However, XQuery sets these properties to false. (3.7.1.3 1.e.ii.C.I) We should
therefore consider this again.

Proposed text:

In 4.3, add new paragraph:

The effect of stripping type annotations is as follows:

* The type of every element node is changed to xdt:untyped

* The type of every attribute node is changed to xdt:untypedAtomic

* The string-value of every element and attribute node remains unchanged

* The typed value of every element and attribute node is set to be the same as
its string-value, with type xdt:untypedAtomic

* The is-id and is-idref properties of element and attribute nodes are unchanged

* The is-nilled property of element nodes is set to false

In 19.2.1.1 (Validation) change the first bullet point to read:

The value strip indicates that the new node and each of the contained nodes will
have the type annotation xdt:untyped if it is an element, or xdt:untypedAtomic
if it is an attribute. Any previous type annotation present on a contained
element or attribute node (for example, a type annotation that is present on an
element copied from a source document) is also replaced by xdt:untyped or
xdt:untypedAtomic as appropriate. The string-value and typed-value and the
is-id, is-idref, and nilled properties are affected in the same way as nodes
subjected to stripping of type annotations from a source tree (see 4.3). Schema
validation is not invoked.
Comment 4 Michael Rys 2006-01-27 20:37:59 UTC
the is-id and is-idrefs property should depend on whether it got defined 
because of a schema constraint (in that case it should be reset to false, 
since the schema does not apply anymore) or by another mechanism (DTD or 
xml:id) in which case it depends on whether they still apply...
Comment 5 Michael Kay 2006-03-10 21:23:34 UTC
After much discussion at various meetings and internal correspondence, and consideration of various use cases, we decided on 9 March that when stripping type annotations, the is-id and is-idrefs properties would be retained.

The main rationale for this is that we can think of use cases where it is useful to retain these properties - for example, when a transformation is added to a pipeline and does not set out to make any change to this part of the document - and it is hard to imagine any cases where retaining the properties will cause problems. We will therefore retain these properties, recognizing that this behaviour differs from XQuery.

The editorial work to make this change has not yet been done so the problem is marked as FIXED but not CLOSED.
Comment 6 Michael Kay 2006-03-13 10:41:27 UTC
I have implemented this decision by making the following changes:

* In section 4.3, before the Note, add:

<p diff="add" at="ZA">When type annotations are stripped, the following changes are made to the source tree:</p>

<ulist diff="add" at="ZA">
<li><p>The type annotation of every element node is changed to <code>xs:untyped</code></p></li>
<li><p>The type annotation of every attribute node is changed to <code>xs:untypedAtomic</code></p></li>
<li><p>The typed value of every element and attribute node is set to be the same as its string value, as
an instance of <code>xs:untypedAtomic</code>.</p></li>
<li><p>The <code>is-nilled</code> property of every element node is set to <code>false</code>.</p></li>
</ulist>

<p diff="add" at="ZA">The values of the <code>is-id</code> and <code>is-idrefs</code> properties are
not changed.</p>

* add to the note ", and any elements and attributes validated as IDs will still be accessible using the
 <xfunction>id</xfunction> function"

* In the first bullet of 19.2.1.1, discussing the meaning of validation="strip", add the following before the final sentence: <phrase diff="add" at="ZA">The typed value of the node is changed to be the same as its string value,
as an instance of <code>xs:untypedAtomic</code>. In the case of elements the <code>nilled</code> property is set to <code>false</code>. The values of the <code>is-id</code> and <code>is-idrefs</code> properties are unchanged.</phrase>

With these changes, the bug is closed.