Hi devs, Denis just reported an issue he have while he is working on generating ids for the database: local reference to an object looks like "space.name^wiki:xspace.class[0]" which is not very local when the absolute reference is "wiki:space.name^wiki:xspace.class[0]" (will let him give more details on what issue it causes). I'm not sure what's the best for this. Here are some ideas: 1/ Relative references for class: change BaseObjectReference to generate a name based on a class reference relative to the document reference. So an absolute reference of an object would give "wiki:space.name^xspace.class[0]" which in turn is not fully absolute even of you can resolve the class reference based on the document. 2/ Local reference for class: pretty much the same thing as 1/ but never contain the wiki. Thing is the current storage does not support class coming from another wiki so would kind of make it "official" in the references generated by BaseObject. 3/ Custom serializer in oldcore: overwrite reference serializers in oldcore and parse the object name to also make the class reference follow the serializer rules (local, compact, etc.). 4/ Object guid as name: use object guid as name but right now guid can't be trusted (sometimes not set, sometimes duplicated, etc.) so it would require to fix some bugs first. 5/ Do nothing: and see this as a limitation of the object reference in the current storage. That means that anyone that really need a local reference for a BaseObject should generate the reference the way he want instead of asking it to BaseeObject before giving it to the serializer. Note that all of these solution generate already currently valid object references, it's mostly about choosing the best default reference. WDYT ? 1/ and 2/ mean that code counting on reference always having absolute reference will be broken, like some event listener on object and object properties modifications probably (would need to check). 3/ is a bit crappy from architecture point of view but at least the base object reference stay fully absolute 4/ is a bit dangerous right now and require to fix several bugs related to guids at least. Also it gives an object reference not very nice from human reading point of view. 5/ does not fix much even if it's possible to manage with a hack helper to get local reference but it's a hack 1/, 3/ and 5/ are nothing else that hacks from my point of view so I'm -0.5 for them 4/ is not a hack but I don't feel very comfortable with object uid that has never really been used (and so have several blocker bug still not fixed) so lets say -0 too 2/ is OK if we say that with BaseObject we will never support classes coming from another wiki. The next storage will have different kind of names for objects anyway not based on classes from what we discussed. It's a +0.5 for me (no solution give me 100% satisfaction but this one is the best until other arguments are exposed) -- Thomas Mortagne