Re: ETF: Possibility of an XML Document Type

 Noah,
 although I see the usefulness of such a type, I'm not sure it is
XMLP WG's task to do this. I agree passing XML documents is and
will be frequent so the way to do it should be standardized.
But if we do this, we could as well go on and standardize maps,
sets etc.
 I think all these things should be standardized as a part of
some Type Library effort which we hear about once in a while.
IMHO the reason for data encoding spec in SOAP is mainly for RPC
and for that we don't need a new simple type for embedding XML
documents.
 The importance of a standard XML Type Library seems to be
growing, or more apparent, so let's hope some work is finally
done in that area.
 So again, IMHO, yes it is a great idea to have a type you know
is an embedded XML document, but no it's not our task to specify
it.
 Kind regards,

                            Jacek Kopecky

                            Idoox
                            http://www.idoox.com/



On Thu, 4 Oct 2001 Noah_Mendelsohn@lotus.com wrote:

 > 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.            To:      <xml-dist-app@w3.org>
 >                       com>                     cc:      (bcc: Noah Mendelsohn/CAM/Lotus)
 >                       Sent by: xml-            Subject: ETF: Issues related to encoding
 >                       dist-app-
 >                       request@w3.org
 >
 >
 >                       10/04/2001 05:38
 >                       AM
 >
 >
 >
 >
 >
 >
 >  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/
 >
 >
 >
 >
 >
 >

Received on Friday, 5 October 2001 10:48:48 UTC