W3C home > Mailing lists > Public > xml-dist-app@w3.org > March 2004

Re: Evaluation of XML Schema Part 2 PER base64Binary type

From: Mark Nottingham <mark.nottingham@bea.com>
Date: Tue, 30 Mar 2004 15:00:03 -0800
Message-Id: <FA6C20B6-829D-11D8-8EFF-000A95BD86C0@bea.com>
To: XMLP Dist App <xml-dist-app@w3.org>

+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: 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
>>> --------------------------------------
>
>
>

--
Mark Nottingham   Principal Technologist
Office of the CTO   BEA Systems
Received on Tuesday, 30 March 2004 18:00:06 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 7 December 2009 10:59:16 GMT