3032 2006-03-21 20:02:48 +0000 Setting the is-id and is-idref property on element nodes 2006-11-16 18:47:54 +0000 1 1 1 Unclassified XPath / XQuery / XSLT Data Model 1.0 Candidate Recommendation PC Windows XP CLOSED FIXED P2 normal --- 1 mike Norman.Walsh public-qt-comments oldest_to_newest 8822 0 mike 2006-03-21 20:02:48 +0000 Section 6.2.4 (constructing element nodes from the PSVI) (repeated in J.2) says: is-id If the type-name is xs:ID or a type derived from xs:ID, true, otherwise false. is-idrefs If the type-name is xs:IDREF or xs:IDREFS, or a type derived from one of those types, true, otherwise false. This means that if the element has a complex type with simple content, and the type of the simple content is derived from xs:ID/xs:IDREF, the property will not be set. I'm sure this isn't what is intended (though it's what I implemented... Incidentally, it was the catalog for the XQTS test suite that revealed the problem!) The same error occurs elsewhere in the Data Model book. For example section 3.3.1.3 says "If the type-name of the node denotes a union type...", "If the type-name of the node is xs:QName, xs:NOTATION, or is derived from one of these types...". In both cases the rule also applies to the content type of a complex-type-with-simple-content. Michael Kay 9416 1 Norman.Walsh 2006-04-24 16:50:25 +0000 Proposal for resolving this issue: Section 6.2.4, make the following changes: is-id If the element is a complex type with element-only content, the is-id property is false. Otherwise, if any of the atomic values in the typed-value of the element is of type xs:ID, or a type derived from xs:ID, the is-id property is true, otherwise it is false. is-idrefs If the element is a complex type with element-only content, the is-idrefs property is false. Otherwise, if any of the atomic values in the typed-value of the element is of type xs:IDREF or xs:IDREFS, or a type derived from one of those types, the is-idrefs property is true, otherwise it is false. In 3.3.1.3, replace the bulleted list with the following: * Where union types occur, the implementation must be able to deliver the typed-value as an instance of the appropriate member type. For example, if the type an element node is my:integer-or-string, which is defined as a union of xs:integer and xs:string, and the string-value of the node is "47", the implementation must be able to deliver the typed-value of the node as either the integer 47 or the string "47", depending on which member type validated the element. * Where types of xs:QName, xs:NOTATION, or types derived from one of these types occur, the implementation must be able to deliver the typed-value as a triple including a local name, a namespace prefix, and a namespace URI, even though the namespace URI is not part of the string-value (see 3.3.3 QNames and NOTATIONS). 9417 2 mike 2006-04-24 17:41:20 +0000 This seems a radical change: it means that we set the is-id property on an element (but not an attribute) that has a list type with an item type of xs:ID, or a union type with a member type of xs:ID. Is that what you intended, and if so, could you explain why? 9421 3 Norman.Walsh 2006-04-24 17:55:30 +0000 I overlooked the fact that I hadn't made the equivalent change in the attribute case. Trying to craft a resolution to this issue, I looked around at what's in XDM and concluded that we were going to have to look at the typed-values of elements and attributes. The fact that we have to look at the typed-value (instead of the type-name) means that we have to look explicitly at the types of the members of the list of atomic values that comprise the typed-value. So what do we do if the list contains more than one element? 1. is-id is true if any of the values is of type xs:ID (or derived from) 2. is-id is true if the first value is of type xs:ID (or derived from) 3. is-id is false I think 1 is the choice of least surprise to users. I could live with 3. I think 2 is wrong. 9422 4 mike 2006-04-24 18:17:46 +0000 Another option is: for is-id: if the typed value contains exactly one item, and that item is an instance of xs:ID, then set the is-ID property. (There's not much point in setting the property if the value contains no items or more than one item, as id() will never retrieve it anyway). for is-idref: OK as written, but applying it to both elements and attributes. I actually think this rule is an improvement: it means that you can create a subtype of xs:IDREF and then construct a list whose items belong to this subtype, and this list will now be treated in the same way as an xs:IDREFS, which was not previously the case. But I'm a little bit concerned that the full implications need some careful thought. 9440 5 Norman.Walsh 2006-04-25 15:08:13 +0000 Mike's rule works for me. 9574 6 Norman.Walsh 2006-05-03 17:50:24 +0000 Fixed in CVS.