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

RE: Issue 189: closed

From: Henrik Frystyk Nielsen <henrikn@microsoft.com>
Date: Sun, 31 Mar 2002 15:18:08 -0800
Message-ID: <79107D208BA38C45A4E45F62673A434D06F9921C@red-msg-07.redmond.corp.microsoft.com>
To: <noah_mendelsohn@us.ibm.com>
Cc: "Jean-Jacques Moreau" <moreau@crf.canon.fr>, <xml-dist-app@w3.org>, "Yves Lafon" <ylafon@w3.org>

Ok, I have added this as an editorial issue so that we don't forget it.
If I understand your concern then I don't think it involves any semantic
changes but rather editorial clarification. If that is not the case then
we can upgrade it to a WG issue.


>>> my reading is that we allow one child EII which 
>>> is the envelope but that other properties 
>>> like base URI, encoding and version are properties
>>> and not child EIIs and hence also allowed
>On reflection, that's a sensible reading,  but I strongly feel 
>that the 
>current text is at best unclear, and arguably misleading.  If 
>this is what 
>we want, we should be explicit as to which properties are allowed 
>(possibly any), and we should spell out any non-obvious 
>implications (if 
>any) of using particular properties.  Do we allow a [base URI] in the 
>infoset?  I thought that came from the binding.  Can the node 
>specify an 
>encoding when sending?  Again, we don't even know whether the 
>binding is 
>encoding at all.  Unparsed entities?  Arguably we've ruled them out 
>elsewhere, but if version is implicitly allowed, why not UE?   
>Etc.  I had 
>originally assumed ONLY the one child.  If we want other 
>properties, we 
>should be clear on the rules and interpretations, I think.  
Received on Sunday, 31 March 2002 18:18:11 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 23:11:48 UTC