RE: Possibility of an XML Document Type

I agree with the drift of this.  Thanks for making it explicit.

 

One concern I would have is in a detail, namely that base64Binary is a
format for representing arbitrary data, but hexBinary is also.  We
should be able to embed a complete XML document using either encoding.
This suggests that a distinct attribute is needed, perhaps something
along the lines of 

 

            <abc xsi:type="xsd:base64Binary"
xsi:mimeType="application/xml">...

 

-----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: Andrew Layman
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/