atom feed5 messages in org.eclipse.emf-devRe: [emf-dev] DocumentRoot?
FromSent OnAttachments
Mark R. DiggorySep 23, 2004 6:11 pm 
Ed MerksSep 24, 2004 3:48 am 
Mark R. DiggorySep 24, 2004 7:13 am 
Ed MerksSep 24, 2004 8:16 am 
Mark R. DiggorySep 24, 2004 9:28 am 
Subject:Re: [emf-dev] DocumentRoot?
From:Ed Merks (mer@ca.ibm.com)
Date:Sep 24, 2004 8:16:53 am
List:org.eclipse.emf-dev

Mark,

If you have no global elements or attributes in your schema, then you won't get a document root.  But of course your schema has not specified a single way to write a document in this case, it's only defined types and stuff that can be used in another schema.  Some schema will need to declare a global element in order to specify the root of a document.

If you are seeing DocumentRoot in your serialization, rest assured that you have not used
XMLResource.OPTION_EXTENDED_META_DATA.   Have you done anything to ensure/verify that the generated
XyzResourceFactoryImpl is being used to load and save your model instances?

Ed Merks/Toronto/IBM@IBMCA mailto: merks@xxxxxxxxxx 905-413-3265  (t/l 969)

"Mark R. Diggory" <mdiggory@xxxxxxxxxx> Sent by: emf-dev-admin@xxxxxxxxxxx 09/24/2004 10:14 AM

Please respond to emf-dev

To emf-dev@xxxxxxxxxxx

cc

Subject Re: [emf-dev] DocumentRoot?

Ed,

Thanks for your response. I'll post all further questions to the newgroup. I was expecting the behavior you outlined below. But, the behavior I was getting (out of the box) with my schema was unexpected and I suspect it had something to do with the structure of my schema, which was primarily a "venetian blind" design. The behavior given the structure of my schema was that the generated EMF model, saved an XML document under the Resource would look like this, serializing the DocumentRoot element you state shouldn't be serialized:

<DocumentRoot>                 ... my expected XML Content ... </DocumentRoot>

And if I regenerated the Schema it would have the DocumentRoot tag "defined" within it. This seemed odd to me. After moving many of my global complexTypes into local definitions and abstracting those that were used in extensions. I was able to eliminate the generation of the DocumentRoot tag. I suspect that when faced with multiple global non-abstract complexTypes something bad happens?

thanks, Mark

Ed Merks wrote:

Mark,

Please use the newsgroup for questions like this.  More folks will benefit from the answers.

I'm not sure how you jumped to the conclusion that a DocumentRoot

results in content that isn't valid according to the schema.  The

purpose of the DocumentRoot is precisely to solve that problem, not to cause it.  When serializing an instance (using XMLResourceImpl with the XMLResource.OPTION_USE_EXTENDED_METADATA) the DocumentRoot, by virtue of which of its containment features is set, determines the root element

QName.  Similarly when reading an instance, the DocumentRoot records the root element QName by virtue of which containment feature is set.    Remember that in 2.0, an EClass corresponds only to a complex type, not an element declaration, so any instance of an EObject corresponds to an instance of a complex type.  As such, if you try to serialize just an instance of a complex type at the root of your Resource, the element

name to use at the root has not been specified/determined.  A

DocumentRoot solves this problem by acting as an implicit root object

that isn't actually serialized, only its one set feature is serialized.

Maybe your confusion stems from saving/loading instances without using

the right resource type and/or the right save/load options?   By default, a resource factory will be generated for you and it should do the right thing, if you register it and use it.

Ed Merks/Toronto/IBM@IBMCA mailto: merks@xxxxxxxxxx 905-413-3265  (t/l 969)

*"Mark R. Diggory" <mdiggory@xxxxxxxxxx>* Sent by: emf-dev-admin@xxxxxxxxxxx

09/23/2004 09:12 PM Please respond to emf-dev

                  To                  emf-dev@xxxxxxxxxxx cc                   Subject                  [emf-dev] DocumentRoot?

                 

Hello,

I'm trying to produce an Encore model and Sources from a Schema. The goal is to produce documents which adhere to the schema by having users work with editors generated using EMF (pretty basic). However, I'm encountering issues because the xml files (and model) all have the Element "DocumentRoot" in the root position, which will not do. Is there any way I can stop the generation of a "DocumentRoot" model type and element? It seems strange that the api makes the assumption that when attempting to generate a model from a schema, that somehow the developer doesn't want the content to be valid against said schema. If 1.1 supported production of valid content (ie no DocumentRoot), what was the decision in 2.0 that diverged from this logic?

 From http://dev.eclipse.org/viewcvs/indextools.cgi/emf-home/main.html?rev=1.74

 > Added support for document roots. In EMF 1.1, a global element  > declaration was mapped to an EClass. In 2.0, every namespace will  > have a single special EClass, by default named DocumentRoot, which  > contains a feature for every global element or attribute declaration  > in the namespace. These represent open content features which may be  > used in feature maps corresponding to wildcards. An instance document  > based on an XML Schema will now contain a single instance of the  > document root, exactly one feature of which will be set to contain  > the actual root element.