W3C home > Mailing lists > Public > xml-dist-app@w3.org > September 2003

Re: XInclude and MTOM

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
Message-ID: <20030915210956.GB24227@daniel.veillard.com>

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:
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 
for the full set of rules for parse="text".


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

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 22:01:24 UTC