RE: editorial changes to Basic Patterns doc.

 
> 1) Section 1. Add the following text to Para 3
 
> "While it is impossible to guarantee that schemata 
> produced using these patterns will work with the 
> universal set of databinding tools, these patterns 
> have been based on real experience with many tools, 
> covering a wide range of languages and platforms."
 
Ok, I went with:

"""
Whilst it is not possible to guarantee that schemata 
produced using these patterns will give a 
good user experience with the 
universal set of databinding tools, the patterns 
contained in this specification have been tested 
with a number of differnet tools covering a variety 
of different programming languages and environments.
"""

> 2) typo: section 1. 4th para lest=least
 
done

> 3) Section 2.4 typo in incomplete sentence.
 
> "Several different patterns are provided for expessing 
> the absence of a value, however minOccurs and nillable."
 
> should be:
 
> "Several different patterns are provided for *expressing* 
> the absence of a value, however minOccurs and nillable 
> are not recommended in combination."

done

> (N.B. going forward a lot more detail is required here 
> I believe....)

> 4) Section 2.4 "Type serializers summarily convert type 
> members with NULL values to xsi:nil declarations, 
> which can cause unintended data changes on the server"
 
> should be qualified:
 
> "Some type serializers ......"
 
Section needs a rewrite this following the resolution 
of ISSUE-7 (there's an ednote to that effect)

> 5) section 2.8 The patterns are listed out of numerical order.
 
OK, fixed. that's the magic of spec-refs

> 6) Section 2.9 is empty and should be removed for the purposes of this snapshot.
 
added an ednote as the section comes from the input document.

> 7) We have some examples in section 3 for which there 
> are 'health warnings' for in section 2. A nicety would 
> be to have a link back to the relevant design consideration .
 
I think we need to number design considerations and attach
an XPath/Schematron assertion to each pattern, especially 
if we're going to generate them as 'warnings'. I'll track
this as a separate issue.
 
Paul

Received on Friday, 21 April 2006 18:49:24 UTC