Re: PROPOSAL: Extensions to XMIReader and XMIWriter interfaces

Krijgsheld, Ronald wrote:
> Martin,
> the name documentURI suggests a URI :). In your answer to Brian about any
> restrictions on the, at that time, called XMIReference.getReference()
> method, you said no. With this new proposal we go in another direction, by,
> at minimum, suggesting a format. Note, that I do not mind this.  

Sure, but it is just a suggestion. For example, you could map all of 
your objects to a virtual directory structure on your web server. E.g.:

http://www.foo.com/models/mof/Model/ModelElement/name

In this case, getDocumentURI() could return 
"http://www.foo.com/models/mof", getLocation() could return 
"/Model/ModelElement/name", and getXmiId() could return whatever you 
want it to.

But, I expect that this type of thing would be rare. You would need a 
custom HrefResolver that worked fairly unintuitively. For the common 
case, the document URI will be a URI for a document ;)

For what you want to do (encode the type in the link), you could do 
something like this:

class CustomXMIReference extends SimpleXmiReference {
    CustomXMIReference(RefObject o, String documentURI, String id) {
          super(documentURI, id);
    }
    public String getLocation() {
         return super.getLocation()
            + ((ModelElement) refObject.refMetaObject())
                 .getQualifiedName().toString();

    }
}

Then your links would look like
    "http://www.foo.com/mof.xml#String[Model, PrimitiveType]"

Probably, you would want a prettier format for the name of the type (at 
the very least, you would probably want to get rid of the spaces).

- Brian