- From: Daniel Veillard <daniel@veillard.com>
- Date: Mon, 15 Sep 2003 23:09:56 +0200
- To: Elliotte Rusty Harold <elharo@metalab.unc.edu>
- Cc: Martin Gudgin <mgudgin@microsoft.com>, xml-dist-app@w3.org
On Mon, Sep 15, 2003 at 01:25:51PM -0400, Elliotte Rusty Harold wrote: > > At 8:31 AM -0700 9/15/03, Martin Gudgin wrote: > > >1. Defined a parse type value of base64Binary that allows binary > >data to be merged into an Infoset. > > > >2. Define whether the character information items merged in 1. are > >to be in canonical form or not. > > Why would this be an issue? Base 64 values only use the ASCII > character set (and not all of that). I think this is always Unicode > normalized. Or did you mean something else by canonical form? If > you're talking about XML canonicalization, that's not really relevant > to the Infoset view. It's very unclear to me what your concern is. Hum, it would be better to accept the same language as XML Schemas Datatype would for interoperability and implementation reasons. I will note that: http://www.w3.org/TR/xmlschema-2/#base64Binary doesn't define itself a lexical representation but reference RFC 2045, so I think it would be simpler if no extraneous rule be applied there (i.e. stick to rfc2045 and not mandate some of the more restrictive rfc2049 set of rules.) W.r.t. the stream of byte included, again it would be nice if the same rules as for XInclude parse="text" were used, i.e. it does not enforce normalization, it default to UTF8 encoding and allows the encoding to be specified on the xinclude element. The xInclude processor then check the encoding of the stream of bytes on import (and that they are within the Char range defined by the XML Rec), see http://www.w3.org/TR/xinclude/#text-included-items for the full set of rules for parse="text". Daniel -- Daniel Veillard | libxml Gnome XML XSLT toolkit http://xmlsoft.org/ daniel@veillard.com | Rpmfind RPM search engine http://rpmfind.net/ http://veillard.com/ |
Received on Monday, 15 September 2003 17:10:13 UTC