- From: James Snell <jmsnell@intesolv.com>
- Date: Mon, 2 Oct 2000 13:54:09 -0700
- To: "'xml-dist-app@w3.org'" <xml-dist-app@w3.org>
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