Don't confuse de-/serialization versus un-/parsing about 101simplejava HOT 6 CLOSED

Adding to this, you are not checking for round-tripping when you de-/serialize.
This is arguably needed.

from 101simplejava.

I am renaming from un-/parsing to de-/serialization in javaReflection, which I am about to submit.

from 101simplejava.

Adding to this un-/parsing vs. de-/serialization confusion.
Serialization includes de-serialization conceptually.
So these must not be separated at a feature/file level.

from 101simplejava.

Are there any serious (maybe even scientific?) sources out there discussing the difference between the two?

The terminology is inconsistent everywhere (e.g. DOM http://www.w3.org/TR/DOM-Parsing/). Technically they serve a similar - if not the same - purpose (with de-/serialization being an implementation of un-/parsing).
The idea here was to avoid this confusion altogeather and use the "more general" name (which also happens to be more applicable in the 101companies namespace as a functional requirement http://101companies.org/wiki/Namespace:Feature) and only vary in method names (since somewhat they refer to technological spaces).

from 101simplejava.

Same problem with Logging vs Tracing (as I'm looking at sax).

It seems that all this naming madness comes from technological spaces (kind of) and there is a need for abstraction to resolve all the confusion.

from 101simplejava.

The point of reference is the feature model.
Please come and talk in person.

from 101simplejava.