Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [mmt-dev] EmfUtil: content-type computation

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


Back to the top