[news.eclipse.tools.emf] XSD key-keyref support revisited

["Adrian Price" <adrianp@xxxxxxxxxxxxxxxxxxxx>]

Good day,

First, my apologies for the length of this posting; I've tried to be 
concise.

My last two EMF consulting engagements have involved the use of EMF in 
conjunction with published application schemas bearing XSD unique/key-keyref 
constraints on non-containment references, which EMF does not currently 
support. Use of xsd:ID would have imposed an unacceptably restrictive 
document-wide key uniqueness constraint. The net result is a rather 
less-than-usable generated model API with such references represented as 
string-type EAttributes rather than typesafe EReferences. Consequently, 
clients require hand-cranked key<-->object accessor/lookup code and JFace 
viewers, data binding support, etc. cannot readily be used.

Now, you can add ecore:reference attributes to the schema xsd:attribute, 
which causes XSD2Ecore to import the attribute as an EReference, but that 
does not solve the problem because EMF still uses the positional URI 
fragment segment syntax. Adding ecore:keys attributes doesn't help either, 
because EMF's //@<feature>[<key>='<value>'] syntax differs from the plain 
key value syntax implied by XSD keyref@field. I could not find an easy way 
to override fragment generation or lookup (because neither Resource 
getURIFragment(EObject) nor getEObject(String) pass the EReference context).

Also, JET2 has a fully functional XPath implementation that can navigate EMF 
models. It seems to need ExtendedMetaData annotations in the domain 
meta-model to map the XPath element and attribute references to Ecore 
EReferences or EAttributes (XSD2Ecore imports these annotations 
automatically). I saw this as a potential basis for evaluating key scopes to 
support key lookup and validation.

Ed Merks stated in dnu9m6$c4e$1@xxxxxxxxxxxxxxxx (Dec' 05):
>Yes, there is no support for key/keyref and no short term plans to add
>it.  There really aren't even long term plans to add it.  The whole
>design is just so XML-centric and maps so very poorly at the metadata
>level.  There's very little you can do with the fully general XPath
>expressions until you have instance data to match it against. I.e.,
>there is no requirement that the referenced ElementB has an @AttrA in
>the schema, only that the instances have such an attribute, but each
>instance could be a different complex type instance with a different
>version of @AttrA of a different type even.  It's kind of a mess, in my
>opinion...

Ed's comments seem to suggest that it would not be possible for EMF codegen 
to generate key-keyref constraints into 'minimally reflective' methods. Even 
so, I'm wondering whether a reflective/interpretive approach might be 
feasible given the existence of JET2's EMF XPath support. My guess is that 
the performance hit on load/save would be an acceptable tradeoff against the 
enhanced client API.

Finally, my research turned up the following reference: 
http://www.priorartdatabase.com/IPCOM/000157944/ ("Modeling XSD:key and 
XSD:keyref Using EMF"). From the (incomplete) text it looks as if someone at 
IBM has looked at the issue and actually come up with at least a design, if 
not an implementation. Does anyone have any information on this?

I'd be interested if anyone has thoughts on this topic.

Thanks,

Adrian Price
TIBCO Software, Inc.