Bug 4766 – [FS] 2.4.4 Example is backwards

Bug 4766 - [FS] 2.4.4 Example is backwards

Summary:

[FS] 2.4.4 Example is backwards

Status:	CLOSED FIXED

Product:	XPath / XQuery / XSLT
Component:	Formal Semantics 1.0
Version:	Recommendation
Platform:	All All

Importance:	P3 minor
Target Milestone:	---
Assigned To:	Michael Dyck
QA Contact:	Mailing list for public feedback on specs from XSL and XML Query WGs

URL:	http://www.w3.org/TR/xquery-semantics...
Whiteboard:
Keywords:

Depends on:
Blocks:
	Show dependency tree / graph

Reported:	2007-06-26 16:30 UTC by Ben Wagner
Modified:	2009-06-22 19:43 UTC (History)
CC List:	0 users (show)

See Also:

Attachments
Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.

Description Ben Wagner 2007-06-26 16:30:02 UTC

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
  };

Comment 1 Ben Wagner 2007-06-26 16:38:33 UTC

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[*/+]
  }

Comment 2 Ben Wagner 2007-06-26 16:43:53 UTC

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
  }

Comment 3 Michael Dyck 2007-06-26 21:01:15 UTC

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.

Comment 4 Michael Dyck 2007-10-04 08:16:20 UTC

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.

Comment 5 Michael Dyck 2009-06-22 19:43:19 UTC

After two years with no reponse from the original reporter,
I am marking this issue CLOSED.