- From: <noah_mendelsohn@us.ibm.com>
- Date: Fri, 19 Apr 2002 20:44:35 -0400
- To: <asirv@webmethods.com>
- Cc: xml-dist-app@w3.org
Asir: on last Wednesday's call, I was asked by the workgroup to prepare a response to your comments regarding the perspective from which the encoding is presented. One of the comments you make is: "I prefer rules for both serializing and de-serializing. If that is not a possibility, then I prefer rules for serializing as opposed to de-serializing." As you know, the text in question traces to a rework that Gudge and I undertook following the meetings in France. The pertinent parts of the resulting specification say: "The encodings are described below from the perspective of a de-serializer. In each case, the presence of an XML serialization is presumed, and the mapping to a corresponding graph is described. When serializing, more than one encoding is typically possible for a given graph. For example, the order in which multi-reference graph nodes are serialized is generally insignificant. When serializing a graph for transmission inside a SOAP message any representation that deserializes to the identical graph MAY be used; when receiving an encoded SOAP message, all representations MUST be accepted. " There are two aspects to your question, so let me deal with them separately. (1) I hope the above makes clear that we have in fact formally specified the rules for both encoding and decoding. The second paragraph quoted gives the rules for encoding, albeit by making reference to the rules for decoding. (2) There is a stylistic question as to whether we might have approached the presentation in the opposite manner. I had the same intuition as you (lead with the encodings), but when I sat down to do the writing I found it was extremely difficult. Gudge read a draft that I wrote, also felt it would be better the "encodings first" way, set out to change it, and reported the same experience as I had had: it was much more difficult. He changed his mind. In short, I believe this traces to the one-to-many correspondence between a particular graph and its many equivalent encodings. So, I don't know whether you'll find that answer appropriate or reassuring, but it does reflect our experience, and the workgroup asked me to communicate that to you. You also lists a number of section headings with titles that refer to "encoding...". As noted in (1) above, I believe we are in fact describing encodings as well as decodings. The two are duals of each other, and are presented as such. For these reasons, the workgroup is proposing to leave the text as it is. Although no formal issue has been opened, I'm sure the workgroup would appreciate your letting us know whether this is an acceptable resolution. ------------------------------------------------------------------ Noah Mendelsohn Voice: 1-617-693-4036 IBM Corporation Fax: 1-617-693-8676 One Rogers Street Cambridge, MA 02142 ------------------------------------------------------------------ "Asir S Vedamuthu" <asirv@webmethods.com> Sent by: xml-dist-app-request@w3.org 04/16/2002 07:55 AM Please respond to asirv To: <xml-dist-app@w3.org> cc: (bcc: Noah Mendelsohn/Cambridge/IBM) Subject: [Issue, March 20th 2002] Serializer vs. De-serializer I raised this issue on March 20th, 2002 [1]. Original text is, "[Comment B] Section 3.1 says that rules are described "from the perspective of a de-serializer". But, - title for section 3.1 is 'Rules for Encoding' - sub section titles are 'Encoding ... - section 3.1.1 is a rule for serializing an edge - section 3.1.3 has rules for serializing generic, struct and array - section 3.1.6 has rules to serialize the value of arraySize - Appendix A has rules for serializing app defined names BTW, in an ideal situation, I prefer rules for both serializing and de-serializing. If that is not a possibility, then I prefer rules for serializing as opposed to de-serializing." [1] http://lists.w3.org/Archives/Public/xml-dist-app/2002Mar/0193.html Regards, Asir S Vedamuthu webMethods, Inc. 703-460-2513 or asirv@webmethods.com http://www.webmethods.com/
Received on Friday, 19 April 2002 21:00:39 UTC