Re: [mmt-dev] EmfUtil: content-type computation

[Ed Willink <ed@xxxxxxxxxxxxx>]

Hi

The traditional solution to opening a URI for contents was to just use 
the protocol and/or extension of the URI.

This didn't work for multi-content extensions such as XML or XMI (or 
even UML).

So content-types were made available. The platform/EMF arrange to use 
the content type for reading files by analysing the file content.

No consideration was given to creating files, since how can you create a 
correct content telepathically. The onus was therefore on applications 
to provide the missing control. This was not trivial so it's been 
overlooked.

Your question provoked consideration of the following three stage resolution
a) identify the most restrictive output meta-model EPackage (easy 
application functionality)
b) convert the EPackage to its content-type (new EMF functionality)
c) create the resource by content type (already available)

This approach just makes the contentTypeToFactory functionality work as 
intended.

I've not studied the QVTo code, so my initial reaction that the extra 
code is rescue heuristics may be unjustified, but even if it is 
redundant, it is dangerous to get rid of this kind of thing for 
compatibility reasons; better to leave the obsolete code in.

    Regards

        Ed Willink


On 18/06/2012 12:56, Uwe Ritzmann wrote:
> Hi Ed,
>
> -------- Original-Nachricht --------
> > Datum: Mon, 18 Jun 2012 11:21:35 +0100
> > Von: Ed Willink<ed@xxxxxxxxxxxxx>
> > An: MMT project developer discussions<mmt-dev@xxxxxxxxxxx>
> > Betreff: Re: [mmt-dev] EmfUtil: content-type computation
> > Hi
> >
> > [...]
> >
> > EmfUtil.createResource(uri,outResourceSet) appears to try to be help by
> > providing some rescue heuristics in case resourceSet.createResource(URI)
> > returns null.
> And I assume that these heuristics would be no longer necessary if ResourceSetImpl.createResource(uri,contentType) would be used.
>
> > Rather than rescue heuristics it is better to tackle the original
> > problem, which as discussed on the EMF thread is to use an EPackage to
> > content-type mapping to enable createResource(URI, content-type) to
> > create an EPackage-relevant resource.
> What would this mapping offer as advantage over the existing three mappings: platformToFactory, contentTypeToFactory and extensionToFactory.
>
> An EPackage can be mapped to extensions or content-types by anyone who feels like implementing a content_parser or extension_parser producing your metamodel and registering it.
> EPackage to Eclipse content-type is generally 1:n.
>
> What would be the added value of an eContentTypeToFactoryMap?
>
> > The deduction of an EPackage from an outResourceSet is not necessarily
> > trivial so the lack of content-type support is probably earlier where
> > the meta-model EPackage is known.
> My apologies, but I am not getting the point of your proposal.
>
> Regards
>
> Uwe