Hi,
I am against XML to be used instead of java serialization in core Jess, or
xmload/xmlsave to replace bload/bsave. But I quite like an idea to have
additionally (as an add-on package) those XML-based extensions (for those
interested to use them).
Short summary of what was said till now:
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...
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.
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.
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).
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.
5. This point is "me-specific", and possibly for 99% of usage patterns
it is not the case. I love Jess for the way it integrates logic and java
objects. I can put arbitrary java objects inside facts, and "reason" upon
them in rules:
Jess> (assert (service (new mypackage.printing.PrintingService)))
Jess> (facts)
f-0 (service <External-Address:mypackage.printing.PrintingService>)
Most of the time however, I would like to hide implementation of some
services, so I am using heavily interfaces and abstract classes. I am
taking advantage of polymorphism and inner classes. Then sometimes I
have facts of the form:
(service video-on-demand service)
(service printing service1)
where service/service1 is an instance of some unknown for me class,
which implements well-known interface (usually I have this object via
RMI from some external service server, and the real type of this class
is not known prior the runtime to my JVM - of course the interface is
known); or service1 is an instance of the anonymous inner class.
Well, I am not sure how XML serialization would cope with that, and
my guess is that it can be even impossible, while e.g. anonymous inner
class is something you cannot re-instantiate from the static attributes
and type information kept in string XML format (with all this dirty
class$1, class$2 names for inner classes). I am not 100% sure, but I
suspect, for that purpose XML will not be able to substitute serialized
objects.
So XML serialization can be used most of the time, but Java
serialization can be used always.
1 point for Java serialization.
This is actually big point, while in my opinion the core functionality
provided by tool like Jess should cover all possible cases, and then
developers can constrain it for theirs more specific needs. My guess is
that to enable XML-enabled fact storage, I have to constrain objects which
are stored in facts to be "normal" objects, or even just beans, or
something like that, and for sure I cannot put inside XML just interface.
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.
Thus, just because of 5, I think bload and bsave should stay as it is, but
xml support as optional addition to that would be great.
Mariusz
---------------------------------------------------------------------
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]
---------------------------------------------------------------------
