W3C home > Mailing lists > Public > www-xml-schema-comments@w3.org > July to September 2001

RE: clarifications on XML Schema base64Binary type

From: Michael Brennan <Michael_Brennan@Allegis.com>
Date: Fri, 27 Jul 2001 12:16:35 -0700
Message-ID: <753B28EF1C2DD411AF1C00B0D0202CB5014D424A@mailhost.hq.allegis.com>
To: "'www-xml-schema-comments@w3.org'" <www-xml-schema-comments@w3.org>
> From: C. M. Sperberg-McQueen [mailto:cmsmcq@acm.org]
> ...
> 3 We reached no consensus on whether XML Schema processors should
> enforce the rules about equals signs and base-64 character count or on
> what the canonical form should be.  The XML Schema WG leans toward
> enforcing the equals-signs-and-character-count rules by writing an
> appropriate regular expression or BNF for the lexical space of
> base64Binary.

+1 on this. Our current implementation relies upon the correct character
count and use of equals signs in conformance with RFC 2045. I strongly
believe this is appropriate.

> On canonical form, the XML Schema WG is currently
> leaning toward either
>    (a) 76 characters from the base64 alphabet, then a newline 
> sequence;
>        repeat as needed; last line of more than 0, less than 76
>        characters, also terminated by newline sequence,
> or
>    (b) 4 characters of base64 alphabet, blank, repeat; replace
>        every fifteenth blank with a newline sequence.  Replace any
>        final blank with a newline sequence.  (So the result is
>        lines of 74 characters containing 15 blank-separated
>        quartets of base-64 characters, and a final shorter line.)

+1 for a.

I also would like to see a note of clarification on character encoding. RFC
2045 explicitly references US-ASCII character encoding. However,
base64binary data in an XML entity should conform to the character encoding
of the containing entity. A note to this effect could help avert some
confusion on the part of some implementors.
Received on Friday, 27 July 2001 15:17:07 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 23:08:53 UTC