|Re: What is the status of XSD roundtrip ? [message #901483 is a reply to message #901449]
||Mon, 13 August 2012 04:50
| Ed Merks
Registered: July 2009
On 12/08/2012 3:32 PM, Seref Arikan wrote:
> Looking at the google search results, I have a feeling that if I start
> with an XSD to generate Ecore model, and make changes to model and
> save as XSD again, the resulting schema contains EMF specific namespaces.
Ecore -> XSD -> Ecore is designed to be a round trip, so if necessary,
non-schema namespace annotations (conforming to what's permitted by the
XML Schema specification) are used to capture information that would
otherwise be lost.
> Is this all that is added to resulting XSD?
XSD -> Ecore -> XSD is not designed to be round trip. XSD -> Ecore is a
lossy transformation so while you'll generally get something close to or
equivalent to the original schema is most common cases, it's not
generally to be expected.
> Surely the namespaces must be there for a reason.
Yes. Do you have specific examples?
> Is it possible to create an Ecore based tool for modifying existing
> XSDs, so that nothing related to EMF will exist in the resulting XSD?
If every detail of the original XSD is important, you should modify it,
not the transformed Ecore and then transform it back.
> A simple example would be creating an Ecore model from the XSD and
> simply changind the name of an attribute, and exporting the model back
> to XSD
Can you be more explicit with an actual example? Then I can explain why
annotations are needed for that case...
|Re: What is the status of XSD roundtrip ? [message #901509 is a reply to message #901499]
||Mon, 13 August 2012 08:07
| Ed Merks
Registered: July 2009
On 13/08/2012 9:35 AM, Seref Arikan wrote:
> Hi Ed, Thanks for the response. This is my use case: there is an XML
> schema which contains all types from an information model. Various
> clinical concepts are designed by using these types, such as a blood
> pressure measurement model. There is no limit to clinical concepts
> that can be designed; this is the very reason the information model
> has been created.
> When a clinical concept is created, it uses a subset of types from the
> information model, not all of them. What I want is to use EMF for this
> clinical concept designer, letting users mix and match types from the
> information model (imported from XSD to ECore), and then I'd like to
> let the user create a new XSD that defines the specific clinical
> model. In this case, the resulting XSD should reference the original
> XSD(s) for types, and it would be just a restructuring of some types
> from the main information model (XSD).
Does this new model have a different namespace than the information
model that's being reused? Each different namespace results in a
different Ecore EPackage and such a package will export to a schema that
imports the namespace of the other models so at worst, you'd need to
update the schema location to refer to the original schema's location.
> Does this sound feasible for an EMF based implementation?
It sounds feasible. Perhaps you'll need to tweak the resulting schema a
bit. E.g., swizzle schema location or strip out unwanted
> Kind regards
Powered by FUDForum
. Page generated in 1.26649 seconds