revxml

[mwieder]

Looking at xmlattribute.cpp, in function CXMLAttribute::GoPrev there's a line

Code: Select all

Bool retval = attribute->next != NULL;

Shouldn't that be

Code: Select all

Bool retval = attribute->prev != NULL;

[LCMark]

Having just had a quick look - I suspect so...

[mwieder]

(I reported this is another thread, but I think it's more appropriate here) libXML is not getting build with a "make development", only with a "make all".
And when I do build libxml, I get an error with an undefined reference to "xmlSAX2StartElementNoNS". It's declared and used in revxml/srcxmldoc.cpp, but the function isn't defined anywhere.

I've managed to massage the libxml2-2.9.1 library files to the point where they compile now except for linking revxml to that one line.

[mwieder]

OK - I think I found the problem. I'll have to merge one more file in from the old directory.

[LCMark]

I get no problems compiling revxml here on either 64-bit (Ubuntu 12.04) or 32-bit (Ubuntu 6.04) Linux. What errors are you getting when attempting to build out of a clean github clone?

The function you refer to is a custom function we added to libxml a while ago to support namespace options - its in SAX2.c.

In regards to the Makefile dependencies in the top-level Makefile, they could do with being improved. For example, revxml needs libz and libxml, but it only depends on libxml at the moment.

[mwieder]

Yeah, I found it in the old SAX2.c file. When I brought in the new libxml files that function disappeared, so I had to bring it back.
Haven't done more than a smoke test, but at least it compiles properly now.

[mwieder]

In revxml.cpp, in the function DispatchMetaCardMessage is

Code: Select all

sprintf(mcmessage,"global xmlvariable;try;send \"%s xmlvariable\" to current card of stack the topstack;catch errno;end try;put 0 into extvariable",messagename);

...and I'm guessing that the reference to "extvariable" should be "xmlvariable".

[mwieder]

I have pushed thirdparty changes to use the latest libxml files and livecode changes to fix the bugs reported above and provide more xml command naming consistency. I still don't like having to have a "rev" prefix before all the XML commands, but I guess we're stuck with that historically.

Next step is to expose the xslt functionality of the library.

[mwieder]

Update - I've got basic xquery functionality exposed. I can now do things like

Code: Select all

put revXMLCreateTreeFromFile(tPath, false, true, false) into tDocID
put xpathEvalExpression(tDocID, "/bookstore/book[price<30]") into tQueryResult

The question now is what to do with the result set. It's tempting to just do what the database library does and leave it dangling, but it might also be nice to have a relationship with the xml id.

[monte]

You could just return a list of paths... Not the most efficient way to do things but it means that the results can easily integrate with the other functions...

[mwieder]

I see I misspoke earlier - I've got basic *xpath* functionality working.
Xquery isn't part of the libxml library.

And what I'm returning right now is a pointer to a list of nodes. There are other functions that can unravel that - for instance I can return a list of all the contents by looping through the pointers, but what I think I'd like to do is return another xml document.

Another problem is that the xpath objects have to be freed explicitly, which is an extra burden on the developer.

[monte]

right so if you returned a list of paths then it would be similar to revXMLChildNodes but with more powerful path expressions... but you would need to return full paths rather than just a list of nodes because you can select nodes on different paths...

[Janschenkel]

I second Monte's suggestion: return a list of matching node (unique) paths.
That way the developer can't forget to free the nodes.
You could of course keep track of them per document and free them along with the doc.

Jan Schenkel.

[mwieder]

OK. That's what I did. I condensed all the xpath stuff down to a single call

Code: Select all

put the revXPathDataFromQuery(pDocID, pXpathExpression) into tResult

which results in a cr-separated list of paths. No need to free any allocated memory.
I still don't like the "rev" prefix, but I'm trying to be consistent and it's easy enough to change.
And I'm wondering now whether it might be better to have the function named "revEvaluateXPath()"
At any rate, the branch is now pushed into my repository.

[Janschenkel]

I think revEvaluateXPath is a better name for the function: revDataFromQuery in revdb is a different animal.
Someday we can just have 'evaluate xpath theXPath in xml tree theXmlTree'

Jan Schenkel.