Re: [emf-dev] DocumentRoot?

[Ed Merks <merks@xxxxxxxxxx>]

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.
> 
> 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
_______________________________________________
emf-dev mailing list
emf-dev@xxxxxxxxxxx
http://dev.eclipse.org/mailman/listinfo/emf-dev