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?

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

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.

Added zopestudio keyword for our own tracking.

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.

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!

New implementation checked in and turned on.

verified