W3C home > Mailing lists > Public > xml-dist-app@w3.org > October 2001

ETF: Possibility of an XML Document Type

From: <Noah_Mendelsohn@lotus.com>
Date: Thu, 4 Oct 2001 12:26:23 -0400
To: xml-dist-app@w3.org
Cc: andrewl@MICROSOFT.com
Message-ID: <OFA36D8788.B7B620D7-ON85256ADB.00592517@lotus.com>
Not sure whether it's in scope now, but I would be very interested in
asking whether the encoding group might explore the invention of one or
more new types which would represent complete, embedded XML documents.  One
example of such a type would be a simple subtype of base64Binary.  The
lexical representation in a SOAP envelope would indeed be base64Binary, but
receiving processors would know to parse the reconstructed bits as an XML
document.    Such documents could be in any desired encoding, could carry
internal subset DTDs, could have IDs that conflict with other IDs in the
envelope and/or with possibly additional encoded documents.  In short, this
would be one of the ways to carry one or more XML documents within a SOAP
envelope.  As an example of the application of such a type, one could carry
one or more schema documents (which might, for example, have ID attributes
that conflict with others in the envelope, might use internal subsets,

David:  is this sort of idea in scope for the ETF workgroup?  If so, I'd
like to encourage its consideration.

Noah Mendelsohn                                    Voice: 1-617-693-4036
Lotus Development Corp.                            Fax: 1-617-693-8676
One Rogers Street
Cambridge, MA 02142

                      Jacek Kopecky                                                                                                                
                      <jacek@idoox.            To:      <xml-dist-app@w3.org>                                                                      
                      com>                     cc:      (bcc: Noah Mendelsohn/CAM/Lotus)                                                           
                      Sent by: xml-            Subject: ETF: Issues related to encoding                                                            
                      10/04/2001 05:38                                                                                                             

 Hello all. 8-)
 As I did for the RPC TF, I've gone through our issues list and
identified the issues that pertain to encoding.
 I have an additional issue that is apparently not mentioned in
the issues list, it's described below as a new issue #xx.

The list:

  #1 "illegal char encoding"
 #18 "top-level is unclear"
 #29 "non-serializable data"

 #17 "encoding usage discussion needed"
 #30 "refs to outside data"
 #48 "custom encoding styles"
 #47 "data model vs. encoding"
 #55 "examples needed"
#129 "examples needed"
 #97 "soap base64 vs schema base64"
#117 "position and offset clarification"

To be closed already:
#112 "encoding faultcode" closed

IMHO does not pertain to data encoding, see below:
 #59 "character encoding"

 Here are my quick comments on some of the issues:

  #1 "illegal char encoding"
probably only partially pertaining to encoding in that we should
say how non-XML names should be mapped to XML when serializing
structs etc.

 #29 "non-serializable data"
Let's just say: in case data doesn't map to our data model, use
a different model/encoding

 #30 "refs to outside data"
We just have to say explicitly how SOAP already does this

 #48 "custom encoding styles"
We just have to say explicitly how SOAP already does this

 #59 "character encoding"
I don't think this is an issue for the ETF, it's mentioned in
the list because it is marked as "enc" in the issues list


 #xx "array information is not XML-ish"

The arrayType, offset and position attributes' values are hiding
non-atomic data (lists of numbers, type references) in a mangled
form in a string. I think this should be changed to be more
XML-like. This should also help clear up some fuzzy areas about
these attributes. I will compose a proposed solution. Yes, it
won't be backwards compatible with soap/1.1 arrays, but for this
issue I dare say "screw backwards compatibility!"

 Best regards,

                            Jacek Kopecky


Received on Thursday, 4 October 2001 13:39:13 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 22:01:16 UTC