> 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