These objections sound more gut then emprirical.
> 0. It is relatively easy to save and upload complex networks of
> objects using serialization, while for XML developer (Ernest ;o) it
> would be necessary to provide complex processing (or reuse code from
> people who did that already). Lets say: no points, something "difficult"
> or "easy" is relative...
The package I found makes xmlsave/xmlload equivalent in difficulty as
bload/bsave
> 1. External dependency`
> Java serialization is build-in feature of Java core, while XML parsing
> is not, yet. That is inconvenience for XML. 0.5 point for Java
> Serialization.
Agreed. Though I think that realistic development environments without
XML toolsets are going to be fewer and fewer. So even .5 seems high to
me. Java XML support is fantastic and apache/cocoon makes it necessary
for java server-side development.
> 2. Size and speed of binary representation.
> Java serialization is slow, and the size is not that small, but XML
> parsing, marshaling and unmarshaling is even slower, and the size of
> the output is even bigger, so 0.5 point for Serialization.
I am not sure that gzipped XML files are a substantially different size
from gzipped binary files. Moreover, the marginal cost of converting
between binary and XML representations is relatively small compared to the
large effort of "flattening" in memory datastructures into serialized
representations.
Applications of schema transformations will be more expensive, but such
actions will only be necessary in exception contexts and so should not be
part of the count.
Note: most of these time estimates are speculation, but until someone
tests, you are in the world of thnking about what work is really required.
> 3. Interoperability of the ruleset's image with other rule-based
> systems.
> Well, here there is one (big) point for XML. Serialization is
> Java-only specific, even more, it is particular system specific, like
> Jess-specific representation in this case (which could be from the
> other hand the advantage from the "binary" save/load perspective,
> depending for what purpose one needs this external storage
> to be used for)
> 1 point for XML. (I could say in terms of interoperability even 2
> points).
I am not sure I buy this. XML save maintains consistency across java
class versions. An interoperability standard would need to figure out how
to handle java objects sanely in non-java rule systems.
I do think that some XML dtd could be used as an interoperability
wire-format, but I think this issue is really orthogonal to saving
rulesets locally.
> 4. One can be interested on producing by means of some external
> software new rules or modify the existing rules inside this external
> image. With XML representation one can easily use some XML-enabled
> software for that, while with serialized representation one has to
> provide his/her own tools for that purpose - 1 point for XML.
This I think is huge and should merit more than 1 point.
Use of XSLT to do rule based schema transformations is a huge win
over more procedural version# switch/case based java implementations.
> 5. This point is "me-specific", and possibly for 99% of usage patterns
> I have no experience with cited by Alex koala package, but I suspect what
> they store are just (normal) object attributes, and it will not work with
> interfaces/anonymous inner classes.
I have no experience with the package either, but only spent 2 minutes
looking. Sinceit works w/ java binaries, I think it would be quite
reasonable to expect it to handle interfaces/anonymous innerclasses as
well (but as they say, RTFM). If it doesn't there is no reason to assume
that you would not find another package that does.
You are also missing the big value add of the XML save. No more class
level version# bookkeeping. 2pts.
-Alex-
___________________________________________________________________
S. Alexander Jacobson Shop.Com
1-212-697-0184 voice The Easiest Way To Shop
---------------------------------------------------------------------
To unsubscribe, send the words 'unsubscribe jess-users [EMAIL PROTECTED]'
in the BODY of a message to [EMAIL PROTECTED], NOT to the
list (use your own address!) List problems? Notify [EMAIL PROTECTED]
---------------------------------------------------------------------
