RE: Closing XML Protocol Last Call issue 395

So, you're implying that there is no infoset that serializes as having, 
for example, an element declaration?  No way to say:  this attribute is of 
type ID?  That stuff just can't be inferred from the infoset, so you 
always need additional information to decide to serialize such things.  I 
don't think that's how I would have built Infoset, but I suppose it's a 
plausible conclusion.   If everyone else agrees, I can live with it.  I 
remain nervous that at best we're missing an opportunity to make crystal 
clear something that now needs quite careful reading,  Still, if nobody 
else shares my concern, let's drop it.  Thanks.

------------------------------------------------------------------
Noah Mendelsohn                              Voice: 1-617-693-4036
IBM Corporation                                Fax: 1-617-693-8676
One Rogers Street
Cambridge, MA 02142
------------------------------------------------------------------







"Henrik Frystyk Nielsen" <henrikn@microsoft.com>
12/05/02 07:26 PM

 
        To:     <noah_mendelsohn@us.ibm.com>
        cc:     "Martin Gudgin" <mgudgin@microsoft.com>, <xml-dist-app@w3.org>
        Subject:        RE: Closing XML Protocol Last Call issue 395
Categories: 
 





>My question is, does it provide a unique encoding (modulo, 
>say, insignificant whitespace) or does it allow wiggle room 
>for you to introduce a <!DOCTYPE > while serializing.

Unless I am missing something, I don't think there is any wiggle room
because we state that the serialization is an XML/1.0 representation of
the SOAP message infoset, no more, no less. IMO, this means that there
is no mechanism for adding things *not* in the SOAP message infoset
including internal subsets because they would require a document type
declaration information item even if parts thereof don't show up in the
infoset.

>  As 
>mentioned in my note to Gudge a minute ago, I think there are 
>some DTD constructions that are not visible in the infoset 
>(parsed entity declarations, attribute declarations w/ 
>defaults).  I don't see 3203 as prohibiting their introduction 
>into the serialization, and that's my problem.  If my concern 
>is justified, I think we close the hole by saying:  "Use the 
>application/soap+xml media type, being sure not to include a 
><!DOCTYPE>."  Or, if we want to disallow it in the media type 
>(which would take application/soap+xml further from 
>application/xml, but would otherwise be OK with me), that 
>would be OK too.

I am still not convinced that it is the Right Thing because the obvious
question would be: 'well, where would "<!DOCTYPE>" come from when
serializing a SOAP message using the mechanism described by the
"application/soap+xml" media type?'

Henrik

Received on Thursday, 5 December 2002 19:32:23 UTC