OK, thanks for clarifying. I hadn't really considered it before, but I think I agree that serialization should be reciprocal. And yes, it does seem like mutating the input stream would violate that reciprocity (though, at the moment, BXMLSerializer does not support writeObject(), so it is sort of an academic issue). G
On Jul 9, 2011, at 6:08 AM, SYSE | Edvin wrote: > Den 08.07.2011 21:28, skrev Greg Brown: >>> Den 08.07.2011 21:04, skrev Greg Brown: >>>> Sorry, I wasn't clear either. :-) I should have asked "what do you mean >>>> by 'it'"? In other words, what do you think breaks the contract defined by >>>> Serializer? >>> >>> That's what I tried to say with this sentence: >>> >>> "If you write an object you expect to get the same object back when you >>> read back the stream you wrote earlier. If you add some mutator to it, >>> that's not serialization anymore, that's something else IMHO". >> >> Right, I read that but I wasn't sure what you were getting at. What >> specifically do you think would violate this reciprocity? > > The first principle I think of when I hear the word Serializer, is that you > can write an object, and later read that same object back again. Even if you > do it over and over, you'd still get the same object. > > If the "ebxml" file mutates the object, let's say to create a collection > somewhere in the hierarchy, then writing this object back to "ebxml" again > would probably describe a collection instead of the original markup that > described an object to be mutated, right? The collection won't have > information on it to be able to reverse-engineer it back to the same state > when writeObject is called. > > -- Edvin > >
