RE: Possibility of an XML Document Type

Noah,
 
I am all in favor of this approach. I believe there must be a way to
"encapsulate" XML documents that, even though are carried by SOAP, are
intended to be processed by applications other than the SOAP engine, and as
such should not be subject to SOAP limitations like DTD and PI exclusion.
 
Ugo

-----Original Message-----
From: Noah_Mendelsohn@lotus.com [mailto:Noah_Mendelsohn@lotus.com]
Sent: Thursday, October 04, 2001 9:26 AM
To: xml-dist-app@w3.org
Cc: andrewl@MICROSOFT.com
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/ <http://www.idoox.com/> 

Received on Thursday, 4 October 2001 16:18:41 UTC