Hi Torben,
I did something similar in the past, however using a different strategy.
The whole thing basically works like this:
1) I have a C++ Prog with an embedded clips engine (and whatever
XML/XSD handling you like)
2) when a request arrives (as XML) look into a mapping table to locate
the matching Clips defclass (which must exist), create an instance of
that class or locate the already existing instance based on
identifying XML attributes
3) Map in XML attributes to Clips instance slots (this may happen
recursively for nested XML structures which yields nested Clips
instances) by calling message handlers
4) Let the Clips engine run
5) If done, either trigger actions from inside the Clips instances or
query instances from the C++ prog to produce a result
This means that all the XML I/O and mapping between XML and Clips
happens mostly in the C++ code using the Clips API - except all logic in
the Clips rules itself. Once I let the engine run (step 4) the C++ prog
does not know anything what's happening in Clips. The mapping stuff was
quite complicated though.
The fundamental idea is to have an equivalent between your XSD and Clips
defclasses and map between each other. Your XML example would then be
something like
(defclass Child (is-a USER)
...
)
(defclass Parent (is-a USER)
(multislot children
(allowed-classes Child)
)
)
and
(definstances x
(foo of Child ...)
(bar of Child ...)
(parent of Parent (children [foo bar]))
...
)
Of course in this example, the defclasses "Parent" and "Child" are quite
static (how are sub-schema of Child named?) but you could also define a
generic
(defclass XmlAttr (is-a USER)
(slot name)
(slot value)
)
(defclass XmlTag (is-a USER)
(multislot children (allowed-classes XmlTag)
(multislot attrs (allowed-classes XmlAttr)
)
This is similar to your approach, only that the parent/child
relationship is already stored nicely as instance slots (no slot
"parent" needed).
Scalability may be an issue, especially with such a generic defclass
(and hence 1000s of instances of XmlTag) may be dangerous if you want to
combine multiple XmlTag instances (since there may be zillions of
partial matches due to all the permutations) - this will most likely a
problem with your original idea too.
Rgds,
tge
On Sat, 2012-10-13 at 16:33 +0000,
clip...@googlegroups.com wrote:
> Today's Topic Summary
> Group:
http://groups.google.com/group/clipsesg/topics
>
> 1. CLIPS and XML? [2 Updates]
> CLIPS and XML?
> Torben Bang Nielsen <
torben.b...@gmail.com> Oct 11
> 10:31PM -0700
>
> Hi all,
>
> Does anyone have experience or ideas for dealing with XML data
> from CLIPS
> code?
>
> What I'm thinking of is building a request/reply framework
> where I can pass
> an XML document (adhering to a given XSD) into CLIPS as facts,
> have the
> rules do their thing and then finally build a response XML
> document that
> adheres to the same of a different XSD.
>
> I'm rather new to CLIPS, but one of the thoughts I've had on
> this is to
> represent each XML element as a deftemplate fact and then link
> a child
> element to its parent using the parent's fact address - does
> this sound
> reasonable?
>
> Something like this:
>
> (deftemplate element
> (slot name (type STRING))
> (slot value (default nil))
> (slot parent (type INSTANCE))
> (slot predecessor (type INSTANCE)))
> (deftemplate attribute
> (slot name (type STRING))
> (slot value (default nil))
> (slot parent (type INSTANCE)))
>
> with these facts:
> f-1 (element (name "Root") (value nil) (parent [nil])
> (predecessor [nil]))
> f-2 (element (name "Parent") (value nil) (parent <Fact-1>)
> (predecessor [nil]))
> f-3 (attribute (name "attr") (value "flip") (parent <Fact-2>))
> f-4 (element (name "Child") (value "foo") (parent <Fact-2>)
> (predecessor [nil]))
> f-5 (element (name "Child") (value "bar") (parent <Fact-2>)
> (predecessor <Fact-4>))
>
> representing this XML document:
> <Root>
> <Parent @attr="flip">
> <Child>foo</Child>
> <Child>bar</Child>
> </Parent>
> </Root>
>
> I suppose this could represent any reasonable XML document
> we'd encounter -
> just seems like it'd be a bit tedious to navigate and then I
> don't know how
> it would scale to big XML documents with thousands of
> elements?
>
> Any examples or ideas would be greatly appreciated.
>
> cheers,
> /Torben
>
>
>
>
> Artem Novikov <
novi...@gmail.com> Oct 13 07:02AM -0700
>
> Parsing something using CLIPS is a bad approach.
> Read about embedding CLIPS.
>
> пятница, 12 октября 2012 г., 13:31:44 UTC+8 пользователь
> Torben Bang
> Nielsen написал:
>
>
>
>
> You received this message because you are subscribed to the Google
> Group clipsesg.
> You can post via email.
> To unsubscribe from this group, send an empty message.
> For more options, visit this group.
>
>
> --
> You received this message because you are subscribed to the Google
> Groups "CLIPSESG" group.
> To post to this group, send email to
CLIP...@googlegroups.com
> For more options, visit this group at
>
http://groups.google.com/group/CLIPSESG?hl=en
>
> --> IF YOU NO LONGER WANT TO RECEIVE EMAIL <--
> Visit this group at
http://groups.google.com/group/CLIPSESG?hl=en
> Click on "Edit my membership" link.
> Select the "No Email" radio button.
> Click the "Save these settings" button.
>
> --> IF YOU WANT TO UNSUBSCRIBE <--
> Visit this group at
http://groups.google.com/group/CLIPSESG?hl=en
> Sign in
> Click on "Edit my membership" link.
> Click the "Unsubscribe" button.
> Note: This appears to be the most reliable way to unsubscribe
>
> Alternately, send email to
CLIPSESG-u...@googlegroups.com. You
> will receive an email which you must respond to as well to
> unsubscribe. Clicking the link mentioned in the unsubscribe reply does
> not appear to work reliably.