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/

Received on Thursday, 4 October 2001 05:38:24 UTC