[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [emf-dev] DocumentRoot?
|
Ed Merks wrote:
Mark,
If you have no global elements or attributes in your schema, then you
won't get a document root.
No, in my schema there is just the one global "xs:element" representing
the root element of the document, in my case it is called "configuration".
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.
This is something I do understand.
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?
I guess I'm just not familiar enough with this aspect of the
serialization. I believe now, with the changes to my schema that this is
now correctly being used. I suspected that when "multiple" global
elements or attributes exist, that this feature was somehow being turned
off during the generation of the model from the schema. I will try to
understand it better by studying the documentation and tutorials further.
thanks for you help,
Mark
*"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
--
Mark Diggory
Open Source Software Developer
Apache Jakarta Project
http://jakarta.apache.org
