RE: Problem with resolution of Issue 221

Terrific, thanks.  As I said in my note, I think the inability of XML to 
nest XML documents is a major shortcoming.  For example, if DTDs are 
allowed, there's no way at all to say: "here's a nested tree with its own 
DTDs, entities, ID scope, etc."  I guess it just wasn't a use case when 
SGML was designed, and XML seems to have inherited the limitation. 
Unfortunately, general XML will probably have to be carried as attachments 
in SOAP.  Also: if you're using XML 1.0 serializations, there's 
potentially the issue of encodings.  You might have a schema developed in 
the US, and an instance document written in, say, China.  You might want 
to carry them in the same SOAP message, but it's not at all clear that the 
same Unicode encoding would be practical for each.  That's just the way it 
is, for now.  Attachments will let you get around this, but in a way 
that's not entirely architecturally pleasing (I.e. you can't put a body in 
an attachment and have the SOAP processing model apply, at least not 
without an extension that says to do that.)

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







"Champion, Mike" <Mike.Champion@SoftwareAG-USA.com>
Sent by: xml-dist-app-request@w3.org
08/27/02 06:03 PM

 
        To:     xml-dist-app@w3.org
        cc:     (bcc: Noah Mendelsohn/Cambridge/IBM)
        Subject:        RE: Problem with resolution of Issue 221




> -----Original Message-----
> From: noah_mendelsohn@us.ibm.com [mailto:noah_mendelsohn@us.ibm.com]
> Sent: Tuesday, August 27, 2002 5:56 PM
> To: Champion, Mike
> Cc: xml-dist-app@w3.org
> Subject: RE: Problem with resolution of Issue 221
>
> 
> * Finally, if the rationale is to allow arbitrary user XML in the
>   body, but then it's somewhere between difficult and impossible
>   anyway. 

Ahh, that's pretty much the clincher for me.

> 
> In short, even a simple capability of carrying PI's introduces
> some complexity into the specifications, into applications and
> APIs, and into conformance testing.

Thanks, that was exactly what I was looking for.

> Having said that, I would also like to point out that the workgroup
> has reached the point that most successful software projects reach,
> where having a stable design and shipping a specification begins to
> grow in importance relative to making every design decision perfectly.

Right.  I was just hoping there was a better rationale, and there does
seem to be.  OK, I'm comfortable with forbidding them entirely, even
if a plausible case can be made in the other direction.

Received on Wednesday, 28 August 2002 09:38:12 UTC