When an XPath expression in an XPathDocDef evaluates
to the empty string, an RDF statement is created, with
an empty string as the object. However, if the
document is updated later such that the expression
returns a non-empty string, the RDF statement just
disappears (rather than updating the object of the
statement using the value of the non-empty string).
This scenario appears to arise only when a statement is
created whose object is an empty string, which means
that the use of the string() function in the test case
below is essential. (In the case of an empty node-set
(rather than a string), no RDF statement is created at
all (as one would expect).) Another data point
demonstrated by the test case below is that merely
updating the docdef resource itself without actually
making any changes to it results in the correct
statement reappearing.
Three files shown below, followed by the sequence of
command-line interactions demonstrating the bug.
testdocdef:
<DocDef xmlns="http://xmlns.4suite.org/reserved">
<RdfMappings>
<RdfMapping>
<Subject>$uri</Subject>
<Predicate>'test'</Predicate>
<Object>string(/foo)</Object>
</RdfMapping>
</RdfMappings>
</DocDef>
empty.xml:
<foo/>
notempty.xml
<foo>hello</foo>
$ 4ss create document /testdocdef testdocdef
$ 4ss create document --docdef=/testdocdef /testdoc
empty.xml
$ 4ss rdf complete --subject=/testdoc --scope=/testdoc
Scope: /testdoc
----------------------------------------
/testdoc test
$ 4ss update document /testdoc notempty.xml
$ 4ss rdf complete --subject=/testdoc --scope=/testdoc
$ 4ss update document /testdocdef testdocdef
$ 4ss rdf complete --subject=/testdoc --scope=/testdoc
Scope: /testdoc
----------------------------------------
/testdoc test hello
Logged In: YES
user_id=371366
Another way to demonstrate this bug is in the Buyer Base
demo, create a new customer with an empty name. Edit the
name so that it's not empty. The new name will not show up
in the customer index (which is generated from RDF), even
though it did go into the customer XML.