24546 - <template> builder can't handle some assertion orderings

Status: VERIFIED FIXED

(Core Graveyard :: RDF, defect, P3)

Description

[Chris Waterson]

Specifically, it should be able to handle the following piece of RDF/XML:

    <rdf:Seq about="Zope:TreeRoot">
        <rdf:li resource="http://localhost:8080" />
    </rdf:Seq>

    <rdf:Description about="http://localhost:8080"
        rdf:seeAlso="http://localhost:8080/zsContainerRDF"
        dc:Title="Zope"
        dc:Identifier=""
        dc:Date="2000/01/19 12:32:59.724 US/Pacific"
        dc:Type="Folder"
        nc:Icon="http://localhost:8080/misc_/OFSP/Folder_icon.gif"
        zope:showInTree="1"
        zope:treeBranchEmpty="false"/>

The reason that it -can't- is that the RDFGenericBuilderImpl::FindTemplate()
fails to find a template when it receives the first assertion about the
<rdf:Seq> that contains 'http://localhost:8080/'. This causes it to -not-
generate a <treeitem> (or whatever) for 'localhost:8080', so subsequent
assertions about 'localhost:8080' go into the bit bucket.

Fixing this in an efficient way is going to require a bit of thought; maybe
keeping a set of "partially matched" rules or something.

rjc: any bright ideas?

Comment 1

[Robert John Churchill]

First skanky rjc idea: batch up all notifications of new assertions until after 
the .rdf file in its entirety has been processed.

Comment 2

[Robert John Churchill]

Skanky rjc thought addendum: guess that's not 100% viable, as you'd still have 
the same problem if the arcs were programmatically added into the graph in a 
similar order to the example above.

Comment 3

[Martijn Pieters]

Added zopestudio keyword for our own tracking.

Comment 4

[Chris Waterson]

Last night, I had a "moment of clarity" with respect to this bug. We'll 
maintain a state machine that represents the template rule match state for an 
RDF resource in the template builder's database.  The state machine will be 
constructed from the <rule> tags in the <template>. The "alphabet" will be the 
condition tests that a rule needs to make; in other words, the state machine 
will test the condition of a rule to change from one state to another. The set 
of states and transition function will be constructed such that, when a rule 
matches, the state machine will be in an "accepting" state. 

I think I have the construction worked out. I'll shove more into the bug report 
soon.

Comment 5

[Chris Waterson]

Initial implementation of the new template stuff is in. Add 
nsXULTemplateBuilder.cpp and nsRuleNetwork.cpp to the build; remove 
nsRDFGenericBuilder.cpp. I'm working on the last bugs and putting in a fixed 
size allocator to get rid of the excessive heap usage. Any additional testing 
you could provide would be much obliged!

Comment 6

[Chris Waterson]

New implementation checked in and turned on.

Comment 7

[Tom Everingham]

verified