Re: Evaluation of XML Schema Part 2 PER base64Binary type

+1

On Mar 30, 2004, at 12:15 AM, Jacek Kopecky wrote:

>
> Cool, that's what I thought would be the outcome. 8-) I also prefer the
> first here. 8-)
>
>                    Jacek Kopecky
>
>                    Systinet Corporation
>                    http://www.systinet.com/
>
>
>
>
> On Mon, 2004-03-29 at 19:58, Martin Gudgin wrote:
>> Either of these formulation is fine with me. I guess I have a slight
>> preference for the first.
>>
>> Gudge
>>
>>> -----Original Message-----
>>> From: [email protected] [mailto:[email protected]]
>>> 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
>>> --------------------------------------
>
>
>

--
Mark Nottingham   Principal Technologist
Office of the CTO   BEA Systems