4766 2007-06-26 16:30:02 +0000 [FS] 2.4.4 Example is backwards 2009-06-22 19:43:19 +0000 1 1 1 Unclassified XPath / XQuery / XSLT Formal Semantics 1.0 Recommendation All All CLOSED FIXED http://www.w3.org/TR/xquery-semantics/#sec_top_level_definitions P3 minor --- 1 bungeman jmdyck public-qt-comments oldest_to_newest 15619 0 bungeman 2007-06-26 16:30:02 +0000 The first example in section 2.4.4 <complexType name="UKAddress"> <complexContent> <extension base="ipo:Address"> <sequence> <element name="postcode" type="ipo:UKPostcode"/> </sequence> <attribute name="exportCode" type="positiveInteger" fixed="1"/> </extension> </complexContent> </complexType> is represented as follows define type UKAddress extends ipo:Address { attribute exportCode of type ipo:UKPostcode, element postcode of type positiveInteger }; has the types of "exportCode" and "postcode" backwards. This should be represented as define type UKAddress extends ipo:Address { attribute exportCode of type positiveInteger, element postcode of type ipo:UKPostcode }; 15620 1 bungeman 2007-06-26 16:38:33 +0000 It doesn't seem worth it to open a whole new bug for this, but in the same section the example Example A type declaration with one element name of type xs:string follows by one or more elements street of type xs:string. define type Address { element name of type xs:string, element street of type xs:string* } should read as [<existing>/<replace with>] Example A type declaration with one element name of type xs:string follow[s/ed] by one or more elements street of type xs:string. define type Address { element name of type xs:string, element street of type xs:string[*/+] } 15621 2 bungeman 2007-06-26 16:43:53 +0000 The example following the previous one Example A type declaration with complex content derived by extension define type USAddress extends Address { element zip name of type xs:integer } seems to have an extraneous "name" and should read Example A type declaration with complex content derived by extension define type USAddress extends Address { element zip [name/] of type xs:integer } 15625 3 jmdyck 2007-06-26 21:01:15 +0000 I agree with all of your suggestions. The last one duplicates a comment at the end of Bug 3871, but the others are new. These changes will eventually appear in the FS errata document, and also be reflected in subsequent versions of the FS document. Consequently, I am marking this issue as RESOLVED FIXED. Please CLOSE the issue to indicate your acceptance of this resolution. 17029 4 jmdyck 2007-10-04 08:16:20 +0000 This issue has been entered as FS erratum E020. The suggested changes have been committed to the source files for the next edition of the FS document. Please CLOSE the issue to indicate your acceptance of this resolution. 25652 5 jmdyck 2009-06-22 19:43:19 +0000 After two years with no reponse from the original reporter, I am marking this issue CLOSED.