RE: ebXML Abandons SOAP

Well... before we get too far along on this discussion, let's back up and
identify exactly WHY XML is currently NOT a good envelope for XML.  


1. CNAME data.  A CNAME cannot contain CNAME data.. i.e.:
       <some_data><![CDATA[ 
		<other_data><![CDATA[ this doesn't work ]]></other_data>  
	 ]]></some_data>

2. ID's and scoping.  ID datatypes are effective throughout the entire
document irregardless of element scope.  

Essentially, what is needed then (as has been mentioned already) is a method
of scoping documents within other documents so that something like the
following would be rougly correct:

<doc>
   <head scope='1'>
      <!-- some xml -->
   </head>
   <body scope='2'>
      <!-- some xml -->
   </body>
</doc>

So that all of the XML contained by the <head> element is considered to be
in a separate XML document than all of the XML contained by the <body>
element.  The <doc> element would be considered to be a global scope.  This
mechanism would entail that the each scope would be validated and parsed
separately from documents within other scopes.  

Now, I realize that this would mean a change in the XML specification to
accomplish this, however, I think that this type of mechanism will be
essential to address this issue.  Scoping would eleminate both issues
mentioned above and allow one XML document to be easily inserted into the
body of another.

It has been mentioned that perhaps namespaces could be used as a scoping
mechanism.  This is a posibility so let's take a look at what that might
look like:

<!-- Approach Number 1 -->

<a:doc>
   <b:head>
      <!-- some xml -->
   </b:head>
   <c:body>
      <!-- some xml -->
   </c:body>
</a:doc>

 
At first, this might seem to work well, but it doesn't for obvious reasons.


<!-- Approach Number 2 -->

<doc>
   <head a:id='1'>
      <!-- some xml -->
   </head>
   <body b:id='2'>
      <!-- some xml -->
   </body>
</doc>

This approach also seems to work well, but it also doesn't work.  The reason
has to do with the fact that no distinction can be made between qualified
elements that are supposed to be in a different scope than qualified
elements that are not in a different scope.  In other words, how would the
parser know that the intention of the document is to have head and body
parsed separately under different scopes?  Basing the judgement on qualied
name is simply not adequate.

<!-- Approach Number 3 -->

Perhaps something like this would be appropriate (the xmlscopedNamespace
attribute is a list linking the namespace to a particular scope with the
pattern "namespace <space> scope-name" i.e. a value of "a head b body" means
that the "a" namespace is in the "head" scope and the "b" namespace is in
the "body" scope.

<doc xmlns:a='some_urn' 
     xmlns:b='other_urn'
     xmlscopedNamespace='a head b body'>
   <a:head id='1'>
      <!-- some xml -->
   </a:head>
   <b:body id='1'>
      <!-- some xml -->
   </b:body>
</doc>

In this instance, the parser could check the xmlscopedNamespace attribute to
determine if a particular namespace has been scoped.  All elements and
attributes qualified by that namespace would then be isolated by the parser
and validated separately from the rest of the document.  This would allow
something like the following to occur (this is just an example):

<SOAP:Envelope
   xmlns:SOAP='http://schemas.xmlsoap.org/soap/envelope/'
   xmlns:HEAD='http://schemas.acmeco.com/header/'
   xmlns:BODY='http://schemas.acmeco.com/body/'
   xmlscopedNamespace='SOAP Envelope HEAD Head BODY Body'>
   <SOAP:Header>
      <HEAD:transaction id='a1' SOAP:mustUnderstand='1'>
          <HEAD:transactionContext>...</HEAD:transactionContext>
      </HEAD:transaction>
   </SOAP:Header>
   <SOAP:Body>
      <BODY:Purchase_Order id='a1'>
          <BODY:Sender>...</BODY:Sender>
          <BODY:Items>...</BODY:Items>
      </BODY:Purchase_Order>
   </SOAP:Body>
</SOAP:Envelope>


Now, because the HEAD and BODY namespaces have been declared as scoped
namespaces, the parser would allow the duplicate ID values on the
HEAD:transaction and the BODY:Purchase_Order elements.  

The XML contained within a particular scope MAY or MAY NOT be well-formed as
far as the other parts of the document which are not part of the same scope,
unless we're talking about attributes.  In other words:

<SOAP:Envelope
   xmlns:SOAP='http://schemas.xmlsoap.org/soap/envelope/'
   xmlns:HEAD='http://schemas.acmeco.com/header/'
   xmlns:BODY='http://schemas.acmeco.com/body/'
   xmlscopedNamespace='SOAP Envelope HEAD Head BODY Body'>
   <SOAP:Header>
      <HEAD:transaction id='a1' SOAP:mustUnderstand='1'>
          <HEAD:transactionContext>...   <!-- MISSING CLOSING TAG -->
      </HEAD:transaction>
   </SOAP:Header>
   <SOAP:Body>
      <BODY:Purchase_Order id='a1'>
          <BODY:Sender>...</BODY:Sender>
          <BODY:Items>...</BODY:Items>
      </BODY:Purchase_Order>
   </SOAP:Body>
</SOAP:Envelope>


Would be OK when the parser is working on the SOAP scope.  An error would be
generated however when the parser begins to work on the HEAD scope.  Make
sense?  

Does any of this make sense or should I go back and load up on a few more
cups of coffee and try again later?

- James

-----Original Message-----
From: xml-dist-app-request@w3.org [mailto:xml-dist-app-request@w3.org]On
Behalf Of Simon St.Laurent
Sent: Monday, October 02, 2000 1:01 PM
To: xml-dist-app@w3.org
Subject: RE: ebXML Abandons SOAP


At 01:42 PM 10/2/00 -0600, Jack, Adam wrote:
>Maybe XML addressing/routing/context information with separate (not
>contained inside the XML) MIME bodyparts is the way to go....

I hate to start a food fight, but I have to admit that I have a _very_ hard
time trying to figure out why anyone would want to preserve, extend, or
encourage MIME multipart transfers for XML.

While I do find some parts of MIME useful (MIME content type identifiers
for instance), I can't say I find the "here's a bunch of blocks of
information" approach of MIME multipart transfers very useful, even for the
email purpose where I encounter them every day.

I don't mind messaging approaches in contrast to RPC approaches, but
reliance on MIME multipart seems like asking for some serious trouble in
the future.  It was built for email, and sort of partly works for email,
but I think it's hard to argue that it does a great job, and I'd like to
suggest that it's time to consider a different approach.

Maybe blocks?  Maybe something else?


Simon St.Laurent
XML Elements of Style / XML: A Primer, 2nd Ed.
XHTML: Migrating Toward XML
http://www.simonstl.com - XML essays and books


-----Original Message-----
From: xml-dist-app-request@w3.org [mailto:xml-dist-app-request@w3.org]On
Behalf Of Simon St.Laurent
Sent: Monday, October 02, 2000 1:01 PM
To: xml-dist-app@w3.org
Subject: RE: ebXML Abandons SOAP


At 01:42 PM 10/2/00 -0600, Jack, Adam wrote:
>Maybe XML addressing/routing/context information with separate (not
>contained inside the XML) MIME bodyparts is the way to go....

I hate to start a food fight, but I have to admit that I have a _very_ hard
time trying to figure out why anyone would want to preserve, extend, or
encourage MIME multipart transfers for XML.

While I do find some parts of MIME useful (MIME content type identifiers
for instance), I can't say I find the "here's a bunch of blocks of
information" approach of MIME multipart transfers very useful, even for the
email purpose where I encounter them every day.

I don't mind messaging approaches in contrast to RPC approaches, but
reliance on MIME multipart seems like asking for some serious trouble in
the future.  It was built for email, and sort of partly works for email,
but I think it's hard to argue that it does a great job, and I'd like to
suggest that it's time to consider a different approach.

Maybe blocks?  Maybe something else?


Simon St.Laurent
XML Elements of Style / XML: A Primer, 2nd Ed.
XHTML: Migrating Toward XML
http://www.simonstl.com - XML essays and books

Received on Monday, 2 October 2000 16:59:55 UTC