RE: Evaluation of XML Schema Part 2 PER base64Binary type

As I say, I can easily live with your preference.  Let's go with that 
unless a groundswell emerges for option #2.

--------------------------------------
Noah Mendelsohn 
IBM Corporation
One Rogers Street
Cambridge, MA 02142
1-617-693-4036
--------------------------------------








"Martin Gudgin" <mgudgin@microsoft.com>
03/29/2004 12:58 PM

 
        To:     <noah_mendelsohn@us.ibm.com>
        cc:     "Jacek Kopecky" <jacek.kopecky@systinet.com>, "XMLP Dist App" 
<xml-dist-app@w3.org>
        Subject:        RE: Evaluation of XML Schema Part 2 PER base64Binary type


Either of these formulation is fine with me. I guess I have a slight
preference for the first.

Gudge 

> -----Original Message-----
> From: noah_mendelsohn@us.ibm.com [mailto:noah_mendelsohn@us.ibm.com] 
> Sent: 29 March 2004 18:33
> To: Martin Gudgin
> Cc: Jacek Kopecky; XMLP Dist App
> Subject: RE: Evaluation of XML Schema Part 2 PER base64Binary type
> 
> Marting Gudgin writes:
> 
> >>Fine, let's just say that the base64 string MUST 
> >> NOT contain any whitespace chars, preceding, 
> >> inline or following. At which point, I'm
> >> not sure why we even care what the Schema datatypes 
> >> PER says.
> 
> OK, no problem at all.  This is at worst redundant with 
> saying that it 
> must be a canonical form.  I can easily live with either of 
> the following 
> (neither of which is wordsmithed.)  The first is intended to 
> be exactly 
> what you've proposed, the second a slight variation.
> 
> * To be optimized, the characters comprising the [children] 
> MUST be in the 
> canonical form of xsd:base64Binary and MUST not contain any 
> whitespace 
> chars, preceding, inline with or following the non-whitespace content.
> 
> -or-
> 
> * To be optimized, the characters comprising the [children] 
> MUST be in the 
> canonical form of xsd:base64Binary.  Note: this implies that 
> there must 
> not be any whitespace chars, preceding, inline with or following the 
> non-whitespace content.
> 
> The former has the advantage of closing off any possible risk that we 
> haven't been clear in our spec, but with the modest risk of 
> (correctly) 
> restating the normative rules of schema datatypes.  The 
> latter runs the 
> risk that I have misinterpreted datatypes, and that we are therefore 
> leaving open some unintentional wiggle room.  As I say, I can quite 
> happily live with either, maybe slight preference for the latter. 
> 
> --------------------------------------
> Noah Mendelsohn 
> IBM Corporation
> One Rogers Street
> Cambridge, MA 02142
> 1-617-693-4036
> --------------------------------------
> 
> 
> 
> 
> 
> 
> 
> 
> "Martin Gudgin" <mgudgin@microsoft.com>
> 03/29/2004 11:29 AM
> 
> 
>         To:     <noah_mendelsohn@us.ibm.com>
>         cc:     "Jacek Kopecky" <jacek.kopecky@systinet.com>, 
> "XMLP Dist App" 
> <xml-dist-app@w3.org>
>         Subject:        RE: Evaluation of XML Schema Part 2 
> PER base64Binary type
> 
> 
> Noah,
> 
> Fine, let's just say that the base64 string MUST NOT contain any
> whitespace chars, preceding, inline or following. At which point, I'm
> not sure why we even care what the Schema datatypes PER says.
> 
> Gudge
> 
> > -----Original Message-----
> > From: noah_mendelsohn@us.ibm.com 
> [mailto:noah_mendelsohn@us.ibm.com] 
> > Sent: 29 March 2004 17:00
> > To: Martin Gudgin
> > Cc: Jacek Kopecky; XMLP Dist App
> > Subject: RE: Evaluation of XML Schema Part 2 PER base64Binary type
> > 
> > I respectfully disagree with this analysis.  My 
> understanding is that 
> > whitespace handling and facets play no role in canonical 
> > lexical forms at 
> > all.  "   abcd  " is not for base64Binary a canonical form.
> > 
> > The whitespace facet in schema is a very strange beast (dare I say 
> > kludge?).  It's a facet that can be declared on a simple type 
> > but plays no 
> > direct role in simple type validation >per the part 2< 
> > datatypes spec. 
> > Rather, it is a hint to users of the datatypes that it might be 
> > interesting to manipulate the whitespace >as a preliminary to 
> > creating a 
> > lexical form for datatypes validation.<  The schema 
> > structures spec is one 
> > such user of datatypes, and it does indeed do such preparation.[1] 
> > Canonical forms have nothing to do with this.  So, "   4" is not a 
> > canonical integer, and "   abcd " is not a canonical 
> base64Binary, at 
> > least IMO.
> > 
> > What is true is that "   abcd " will validate and will map to 
> > the same 
> > point in the value space as "abcd" if you were to try 
> validation via 
> > schema structures (which we don't).  Note that if another 
> > spec, say RDF, 
> > chooses to use the datatypes recommendation then it is 
> RDF's business 
> > whether or not to honor the whitespace facet.  This stands in sharp 
> > contrast to most every other facet, as the rest are pretty much 
> > universally enforced for all users of datatypes.
> > 
> > Thanks!
> > 
> > Noah
> > 
> > [1] 
> > http://www.w3.org/TR/xmlschema-1/#section-White-Space-Normaliz
> > ation-during-Validation
> > 
> > --------------------------------------
> > Noah Mendelsohn 
> > IBM Corporation
> > One Rogers Street
> > Cambridge, MA 02142
> > 1-617-693-4036
> > --------------------------------------
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> > "Martin Gudgin" <mgudgin@microsoft.com>
> > Sent by: xml-dist-app-request@w3.org
> > 03/29/2004 07:50 AM
> > 
> > 
> >         To:     "Jacek Kopecky" <jacek.kopecky@systinet.com>
> >         cc:     "XMLP Dist App" <xml-dist-app@w3.org>, (bcc: Noah 
> > Mendelsohn/Cambridge/IBM)
> >         Subject:        RE: Evaluation of XML Schema Part 2 
> > PER base64Binary type
> > 
> > 
> > 
> > Well, if we say that elements have content whose characters 
> are in the
> > canonical lexical form of xs:base64Binary then the leading/trailing
> > whitespace is stripped/ignored. I can see us calling this out 
> > in the XOP
> > spec, essentially saying that "   abcd   " is treated as "abcd".
> > 
> > Gudge
> > 
> > > -----Original Message-----
> > > From: Jacek Kopecky [mailto:jacek.kopecky@systinet.com] 
> > > Sent: 29 March 2004 13:46
> > > To: Martin Gudgin
> > > Cc: XMLP Dist App
> > > Subject: RE: Evaluation of XML Schema Part 2 PER base64Binary type
> > > 
> > > So can we guarantee to transfer the infoset with fidelity? Or 
> > > do we have
> > > to restrict the canonical form to that with no leading 
> and trailing
> > > whitespace in XOP?
> > > 
> > > Jacek
> > > 
> > > On Mon, 2004-03-29 at 14:21, Martin Gudgin wrote:
> > > > Yup, because at the schema level it's actually "abcd"
> > > > 
> > > > Gudge 
> > > > 
> > > > > -----Original Message-----
> > > > > From: xml-dist-app-request@w3.org 
> > > > > [mailto:xml-dist-app-request@w3.org] On Behalf Of 
> Jacek Kopecky
> > > > > Sent: 29 March 2004 13:16
> > > > > To: Martin Gudgin
> > > > > Cc: XMLP Dist App
> > > > > Subject: Re: Evaluation of XML Schema Part 2 PER 
> > base64Binary type
> > > > > 
> > > > > 
> > > > > Gudge, does the whitespace stripping rule mean that "  abcd" 
> > > > > is also in
> > > > > canonical form?
> > > > > 
> > > > > Jacek
> > > > > 
> > > > > On Mon, 2004-03-29 at 12:24, Martin Gudgin wrote:
> > > > > > Dear XMLPers,
> > > > > > 
> > > > > > I took an action on last weeks call to take a look at 
> > > the proposed
> > > > > > edited recommendation of XML Schema Part 2[1] WRT the 
> > > base64Binary
> > > > > > type[2]. 
> > > > > > 
> > > > > > The description of the base64Binary type now contains a 
> > > BNF and a
> > > > > > canonical lexical form. The canonical lexical form 
> contains no
> > > > > > whitespace characters within the stream of base64 
> > > > > characters. Whitespace
> > > > > > characters at the beginning and/or end of the 
> stream of base64
> > > > > > characters are stripped due to the whitespace facet of the 
> > > > > type having a
> > > > > > value of collapse. Thus any canonical lexical form of 
> > > > > base64Binary is
> > > > > > one line of base64 characters.
> > > > > > 
> > > > > > I believe that the addition of a canonical lexical form 
> > > > > satisfies our
> > > > > > requirements WRT XOP/MTOM.
> > > > > > 
> > > > > > Regards
> > > > > > 
> > > > > > Gudge
> > > > > > 
> > > > > > [1] http://www.w3.org/TR/2004/PER-xmlschema-2-20040318/
> > > > > > [2] 
> > > http://www.w3.org/TR/2004/PER-xmlschema-2-20040318/#base64Binary
> > > > > > 
> > > > > 
> > > > > 
> > > 
> > > 
> > 
> > 
> > 
> > 
> > 
> 
> 
> 
>

Received on Monday, 29 March 2004 13:08:58 UTC