Re: Possibility of an XML Document Type

Thank you Noah. This is an excellent idea !!

Asir S Vedamuthu

webMethods, Inc.
703-460-2513 or asirv@webmethods.com
http://www.webmethods.com/
  ----- Original Message ----- 
  From: Noah_Mendelsohn@lotus.com 
  To: xml-dist-app@w3.org 
  Cc: andrewl@MICROSOFT.com 
  Sent: Thursday, October 04, 2001 12:26 PM
  Subject: ETF: Possibility of an XML Document Type


  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, etc.)

  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.com>



       

                Jacek Kopecky <jacek@idoox.com>
                Sent by: xml-dist-app-request@w3.org 
                10/04/2001 05:38 AM
       

        To: <xml-dist-app@w3.org>
        cc: (bcc: Noah Mendelsohn/CAM/Lotus)
        Subject: ETF: Issues related to encoding 


  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"

  Editorial:
  #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


  New:

  #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

  Idoox
  http://www.idoox.com/