[Scott wrote to me...] If have the following menu items: <menu name="Move Message" datasources="rdf:mailnews" id="mailbox:/" open="true"/> <menu name="Copy Message" datasources="rdf:mailnews" id="mailbox:/" open="true"/> Both of them show up as "Move Message" I'm pretty sure the syntax is right. I wan to be able to have both the move message and copy message menus rooted with the folders. The folders are showing up fine, but the menu item names are wrong. Or, is this a menu bug, or my bug? [My response was...] Doh! Design error in the language, I think. I will log this as a bug vs. me, and Hyatt and I will have to figure this out. Here's the long answer (I'll put this in the bug report, too.)... When XUL is read in, it gets converted into an RDF graph (which makes it really easy to glue in XUL fragments and other data sources). The problem you're seeing here is object identity. The XUL content sink (which does the translation from XUL to the graph) assigns object identity using the "id" attribute. Unfortunately, it's assigning these two menu items the same object identity! (In the graph, it probably gives the object both names; the graph-to-content model builder is dumb and resolves the clash by just picking the first name attribute it finds.) So this means that our syntax is not sufficient: we may need to go back to the days of "rdf:id". Hyatt, do you have any other suggestions?

David Hyatt wrote: I knew this would come up eventually. :) I think we need to do away with ID pointing to RDF resources and come up with a new RDF-namespaced attribute that is used to point to an rdf resource... e.g., <menu name="Bookmarks" id="bookmarksMenu" rdf:resource="NC:BookmarksRoot"/> This item is NOT the same item as the actual RDF bookmarks root, but its children come from the root. That's it... it doesn't pick up attributes from the bookmarks root. All it does is makes sure the children are coming from that resource. Then we should just say that id never points to an RDF resource. The way you do re-rooting or manipulation is by messing around with this other attrubte (e.g., rdf:resource). Chris Waterson wrote: I will make it so; rdf:resource it is. I'll figure out a better syntax for column headers. Put this in the bug for posterity's sake, too. David Hyatt wrote: You'll want to still use the element map based on ID, but in the SetAttribute code you need to break out re-rooting and re-mapping into separate cases... one occurs on rdf:resource now and the other occurs on id.

Slipping to M5.

This is probably going to get fixed as part of a big content model hack that Hyatt and I need to do after M5.

Makring this as wontfix: we may re-open it later if absolutely necessary, but fixing this may cause as many problems as it solves. Scott, the specific problem that _you_ were seeing with menus was actually a bit different: see bug 5991, which Hyatt fixed last night. I think you should be okay now.

Since this just got reopened, I'll point out that this didn't solve the problem I was seeing with multiple Move menus even though a Move and Copy menu were specified in the XUL file.

Just to clear this up, this means that DOM Nodes will no longer have the "ID" attribute set to the URI of the RDF Resource that it corresponds to. Right?

Right. The XUL syntax will use "ref=" to refer an RDF resource; e.g., <tree> ... <treebody> <treeitem id="Boo" ref="NC:PersonalToolbarFolder" /> <treeitem id="Boo2" ref="NC:PersonalToolbarFolder" /> </treebody> </tree>

So I think that I've fixed this. The way I fixed it was painfully stupid. GenericBuilder (and any of its descendants) first look for a "ref=" attribute to determine the identity of an element. If it's there, they treat that as the identity. If it's not, they fall back on the "id=" attribute. XUL Builder looks only at "id=" attributes, patently ignoring "ref=" when it comes to building content. That means that a content model like this... <tree> <treebody> <treeitem id="1" ref="NC:PersonalToolbarFolder" /> <treeitem id="2" ref="NC:PersonalToolbarFolder" /> </treebody> </tree> ...will be built properly. The document.getElementById('1') and document.getElementById('2') methods will return the proper elements. N.B. that document.getElementById('NC:PersonalToolbarFolder') won't work. The content that gets built "beneath" the treeitems will show the RDF resource as an "id=" attribute: because the GenericBuilder always "falls back" to "id=", it allows the children of the treeitem to be recursively built properly. Another implication of the "fallthrough" is that a content model like this (i.e., specified the "old way")... <tree> <treebody id="NC:BookmarksRoot" /> </tree> ...will still work properly. The down side is that we will be "falling through" to ask for "id=" probably 99% of the time in the GenericBuilder. I seriously doubt at this point that it's a concern, but it is annoying. Unless anyone has major objections, I'll check this in (along with an appropriate fix for the mailnews menu) when the tree opens.

Changes checked in.

code level fix. i'm marking as verified. if you disagree, please scold me as appropriate.