[ebBP] 5/24/2004: WI-44-57 Whitespace [RSD]

["Monica J. Martin" <Monica.Martin@Sun.COM>]

OASIS.ebBP.WI-44-57-Use of Whitespace and Constraints;
Topic|;
Point|Summary for Opening of Another Quorum Vote 31 May 2004;
Attachment|http://www.oasis-open.org/archives/ebxml-bp/200402/msg00250.html; 

Attachment|http://www.oasis-open.org/archives/ebxml-bp/200404/msg00053.html;
Attachment|http://www.oasis-open.org/archives/ebxml-bp/200403/msg00096.html;
Attachment|http://www.oasis-open.org/archives/ebxml-bp/200403/msg00108.html;

mm1@
In the informal F2F in New Orleans in late April 2004, the group 
recommended the following on WI-44-57 Use of Whitespace and Constraints:

Original Work Item 44 and 57:
Constraints on white space - Should constraints be placed on the use of 
xsd:string in usage in BPSS or left to implementation and deployment?
Define what facets, if any should be used on the data types used on all 
or specific BPSS elements. In XSD, the xsd:string can use preserve, 
collapse and replace whitespace facets to ensure consistency. What 
should the BPSS use?

Key requirements:

    * If ebBP responsibility, what mechanisms may be used:
          o

xsi:preserveSpace="" (in instance)

          o

Use of NormalizedString and facets

          o

Leave as an implementation detail
      

    * If whitespace is an implementation detail for ebBP - should this
      be handled in implementation not the specification?
    * How do we provide guidance to implementers?

RECOMMENDATION from informal TC meeting in New Orleans:

    * v2.0: Discussed with ebBP and CPPA teams. Consensus was to leave
      the white space issue to implementation and trigger a
      fault/exception. Don't use normalized string nor the XML instance
      suggestion from Webber.
    * v2.0: Put hints in technical specification.

Vote Question WI-44-57:
===============================================================================================
Do you agree that:

No constraints SHOULD be placed on the xsd: string. These constraints 
SHOULD be handled by an implementation detail, and if found to err, 
raise an error.

The technical specification SHOULD provide a warning or implementor's 
hint about this possible condition. If appropriate, this hint SHOULD be 
referenced in descriptive text in the technical specification and any 
well-formedness rules referenced that may assist in ease of development.

References:
Martin, boundaries for v2.0 scope, 24 February: 
http://www.oasis-open.org/archives/ebxml-bp/200402/msg00250.html
Martin, informal F2F agenda and summary, 
http://www.oasis-open.org/archives/ebxml-bp/200404/msg00053.html
Martin, Summary: 
http://www.oasis-open.org/archives/ebxml-bp/200403/msg00096.html
Webber, suggestion, 29 March: 
http://www.oasis-open.org/archives/ebxml-bp/200403/msg00108.html
======================================================================================== 


This email and today's meeting mention serve as the 7-day notice on this 
vote that will open 31 May 2004 and close 8 June 2004.

@mm1