Re: [emf-dev] DocumentRoot?

["Mark R. Diggory" <mdiggory@xxxxxxxxxx>]

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.
>
> Cheers,
> Mark Diggory
>
>
>
> --
> Mark Diggory
> Open Source Software Developer
> Apache Jakarta Project
> http://jakarta.apache.org
> _______________________________________________
> emf-dev mailing list
> emf-dev@xxxxxxxxxxx
> http://dev.eclipse.org/mailman/listinfo/emf-dev

--
Mark Diggory
Open Source Software Developer
Apache Jakarta Project
http://jakarta.apache.org