That actually did the trick!!!
I haven't tested any other scenarios so I don't know if it will work
with all xsd's - but I am happy none the less.
Since I (at the moment) did not want to change code in EMF I had to pull
down the entire createFeature method (since it was already overridden)
from XSDECoreBuilder and changed at the spot you pointed out:
// NON-TUSCANY
int existingIndex =
eClass.getEAllStructuralFeatures().indexOf(eClass.getEStructuralFeature(
name));
if (existingIndex > -1) {
eClass.getEStructuralFeatures().set(existingIndex, eReference);
} else {
eClass.getEStructuralFeatures().add(eReference);
}
Now the test class succeds even using DocumentRoot!!!
The way these changes have been implemented by pulling entire methods
from EMF is not that nice.
The only thing I can come up with at the moment is to squeece in class
between SDOXSDECoreBuilder and XSDECoreBuilder and let that class hold
the slightly modified EMF code.
Once again thanks a lot to all of you guys.
/Chr
-----Original Message-----
From: Yang ZHONG [mailto:[EMAIL PROTECTED]
Sent: 14. februar 2007 22:12
To: [email protected]
Subject: Re: SDO (Types) Registry
Your patch works fine from the perspective of generating only one
DocumentRoot and only one mixed/nameSpaces/schemaLocations.
However, two Properties are generated: TestElementX and TestElementX1
with
different Type.
You may want to remove one of them.
On 2/14/07, Christian Landbo Frederiksen <
[EMAIL PROTECTED]> wrote:
>
> And that was not a consequense of the DocumentRoot issue?
>
>
> -----Original Message-----
> From: Yang ZHONG [mailto:[EMAIL PROTECTED]
> Sent: 14. februar 2007 22:00
> To: [email protected]
> Subject: Re: SDO (Types) Registry
>
> My previous email has mentioned two "TestElementXType", the old and
the
> new
> one.
> Do you want to check it out?
>
> The new TestElementXType instance is *not* an instance of the old
> TestElementXType,
> just like a class instance is not an instance of a class loaded by
> different
> ClassLoader from the same .class file.
>
>
> On 2/14/07, Christian Landbo Frederiksen <
> [EMAIL PROTECTED]> wrote:
> >
> > Let me just follow up.
> >
> > When I don't create the DataObject using the property found on
> > DocumentRoot
> >
> > I get an error doing this:
> >
> >
System.out.println(XMLHelper.INSTANCE.save(documentDataObject,
> > namespace, "TestElementX"));
> >
> >
> > java.lang.ClassCastException: The feature 'TestElementX's type
> > 'TestElementXType' does not permit a value of type
'TestElementXType'
> > at
> >
>
org.eclipse.emf.ecore.impl.EStructuralFeatureImpl$BasicFeatureMapEntry.v
> > alidate(EStructuralFeatureImpl.java:2843)
> > at
> >
>
org.eclipse.emf.ecore.util.FeatureMapUtil.createEntry(FeatureMapUtil.jav
> > a:146)
> > at
> >
>
org.eclipse.emf.ecore.util.BasicFeatureMap.createEntry(BasicFeatureMap.j
> > ava:94)
> >
> > /Chr
> >
> > -----Original Message-----
> > From: Christian Landbo Frederiksen
> > [mailto:[EMAIL PROTECTED]
> > Sent: 14. februar 2007 20:58
> > To: [email protected]
> > Subject: RE: SDO (Types) Registry
> >
> >
> > The way I read your answer here is that all my problems have been
> solved
> > with the changes done so far.
> >
> > I fact I did not know that I was trying to add or replace individual
> > properties in a single type :)
> >
> > Total redefinition is fine for me.
> >
> > Now I see it is the way I handle DocumentRoot that is the problem
and
> > this is only due to that fact that I don't know how else to get the
> > correct property.
> >
> > If I call DataFactory.INSTANCE.create(namespace, "TestElementXType")
I
> > actually get a dataobject but if I try to generate XML from it the
> > element isn't called <TestElementX>. That was why I first found the
> > TestElementX property from the DocumentRoot and the created
DataObject
> > from that.
> >
> > Is there a way to create a DataObject using
> > DataFactory.INSTANCE.create(namespace, "TestElementXType") and then
> > generate XML with property name <TestElementX> ?
> >
> > /Chr
> >
> > P.S Is 'Patch' that GNU thing for Linux or is there an eclipse
plugin
> or
> > something?
> >
> >
> >
> > -----Original Message-----
> > From: Frank Budinsky [mailto:[EMAIL PROTECTED]
> > Sent: 14. februar 2007 20:26
> > To: [email protected]
> > Subject: RE: SDO (Types) Registry
> >
> > Looking at your test program, I can see that what you're trying to
do
> is
> >
> > more than I thought, so it's going to be harder. Let me explain.
> >
> > In the FIRST part, you define a Type named "TestElementXType". Then
in
> > SECOND, you add a second Type: "TestElementYType", which should work
> > with
> > the "true" added to XSDHelper.define(), which allows it to proceed.
In
> > the
> > THIRD part, you redefine Type "TestElementXType", which should work
> with
> >
> > the addToSortedList() change. That's my theory, anyway :-)
> >
> > What isn't working, since we haven't done anything to support it, is
> > incremental addition/modification of the properties in a Type. Right
> > now,
> > all we have is the ability to add new types or completely replace a
> type
> >
> > with a new version (like you're doing for TestElementXType in part
> > THREE).
> > You can't add to or replace individual properties in a single type,
> > which
> > is what you're also trying to do with the global elements/properties
> in
> > the "DocumentRoot" Type.
> >
> > To test this theory, you could change the global element in the
first
> > schema to something like this:
> >
> > <element name="RootElement" type="xsd:AnyType"/>
> >
> > and then delete the global elements in the second and third schemas.
> >
> > This way, you would define the "DocumentRoot" Type in the first call
> to
> > XSDHelper.define() and it would contain the property "RootElement".
On
> > the
> > second and third calls to TypeHelper.define(), since you have no new
> > global elements, it won't change/replace the "DocumentRoot", which
is
> > causing the problem.
> >
> > I think you should try to get this much working first, then we can
> think
> >
> > about how to specially handle the DocumentRoot. Note that if we just
> > change things to allow you to also add new properties or change
> > properties
> > in a Type, then it wouldn't be doing the right thing to
> > "TestElementXType"
> > in the THIRD part - you would have ended up with a
"TestElementXType"
> > that
> > has 4 properties (2 double and 2 integer) instead of a redefinition.
> >
> > Frank.
> >
> > P.S. please try to get patch working, so that you can send us just
the
> > delta for existing files that you change.
> >
> >
> >
> > "Christian Landbo Frederiksen"
> <[EMAIL PROTECTED]>
> >
> > wrote on 02/14/2007 01:30:41 PM:
> >
> > > I have created https://issues.apache.org/jira/browse/TUSCANY-1113
> > >
> > >
> > >
> > > -----Original Message-----
> > > From: kelvin goodson [mailto:[EMAIL PROTECTED]
> > > Sent: 14. februar 2007 19:03
> > > To: [email protected]
> > > Subject: Re: SDO (Types) Registry
> > >
> > > Hi Christian,
> > > it would be good to get to a stage where we can exchange code
and
> > > replicate issues in quick turnaround and attack this together. I
> > > haven't
> > > had a chance to work with the code you attached earlier yet.
> > >
> > > Frank suggested attaching the sources you are having problems with
> to
> > a
> > > JIRA. If you were able to do that that would be really helpful.
> Just
> > > go to
> > > http://issues.apache.org/jira/browse/TUSCANY and create a new
issue
> as
> > > an
> > > "Improvement" and paste your scenario into the description. Then
I
> > can
> > > try
> > > and replicate your issues in an eclipse 3.2 workspace.
> > >
> > > It would be good to get you up and running with subversion so that
> you
> > > could
> > > attach patches rather than files. It's tempting to suggest that
we
> > have
> > > an
> > > IRC chat on the Tuscany channel and really interactively pursue
this
> > > (there's some info on IRC connection here
> > > http://incubator.apache.org/tuscany/get-involved.html) . We could
> > also
> > > use
> > > pasetbin (http://pastebin.com/) in conjunction with IRC to quickly
> > share
> > > code snippets. Unfortunately I have to leave the office in about
15
> > > minutes
> > > (working in UK), but I'll see if I can get back to this later
this
> > > evening. I assume you are in Denmark, yes? I'll make it a
> priority
> > to
> > > try
> > > to support you interactively either later this evening or in the
> > > morning. If
> > > you fancy this then please let me know when is convenient for you.
> > >
> > > Best Regards, Kelvin.
> > >
> > > On 14/02/07, Christian Landbo Frederiksen <
> > > [EMAIL PROTECTED]> wrote:
> > > >
> > > > Im pretty sure version 7 (which I am using) is based on 3.2 but
> > > > otherwise you are right :)
> > > >
> > > > -----Original Message-----
> > > > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
> > > > Sent: 14. februar 2007 18:02
> > > > To: [email protected]
> > > > Subject: RE: SDO (Types) Registry
> > > >
> > > > Chr:
> > > >
> > > > Actually, Rational App. Dev is based on Eclipse 3.0, not the
> > bleeding
> > > > edge
> > > > 3.2. This is a pain for us as well, as we would like to use at
> least
> > > 3.1
> > > >
> > > > plug-ins for our developers, but it's never a good idea to
install
> > > > Eclipse
> > > > plug-ins in to RAD (we've had a lot of problems with that,
> > > particularly
> > > > the Maven plug-in)
> > > >
> > > > -
> > > > Brandon Werner
> > > >
> > > >
> > > >
> > > >
> > > >
> > > > "Christian Landbo Frederiksen"
> > > <[EMAIL PROTECTED]>
> > > >
> > > > 02/14/2007 11:30 AM
> > > > Please respond to
> > > > [email protected]
> > > >
> > > >
> > > > To
> > > > <[email protected]>
> > > > cc
> > > >
> > > > Subject
> > > > RE: SDO (Types) Registry
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > > I too believe they are related.
> > > >
> > > > I am currently using Rational App. Dev. which is based on
Eclipse
> > 3.2
> > > so
> > > > it ought to be able to do what you mention, otherwise I'll
> download
> > > and
> > > > set it up in Eclipse.
> > > >
> > > > A guide to setting it up with regards to patch files would be
> great.
> > > > I'll look into submitting this issue via JIRA.
> > > >
> > > > Btw. clearing xsdComponentToEModelElementMap didn't help.
> > > >
> > > > /Chr
> > > >
> > > >
> > > > -----Original Message-----
> > > > From: Frank Budinsky [mailto:[EMAIL PROTECTED]
> > > > Sent: 14. februar 2007 16:04
> > > > To: [email protected]
> > > > Subject: RE: SDO (Types) Registry
> > > >
> > > > Hi Christian,
> > > >
> > > > My guess is that both of these problems are related.
> Unfortunately,
> > I
> > > > don't have time to look at it myself right now, but my guess is
> that
> > > you
> > > >
> > > > probably need to make sure the cached mapping (Yang mentioned
> below)
> > > is
> > > > updated. Maybe something like this is needed:
> > > >
> > > > public void generate(XSDSchema xsdSchema, boolean
> forceOverwrite)
> > > > {
> > > > if (forceOverwrite) xsdComponentToEModelElementMap.clear();
> > > > super.generate(xsdSchema);
> > > > }
> > > >
> > > > Yang has volunteered to help get this working, but I think that
we
> > > need
> > > > a
> > > > better way to collaborate. Maybe you can open a JIRA request for
> > this
> > > > feature and then attach the test case and a patch to it (sending
> > your
> > > > changes in emails is very difficult to work with).
> > > >
> > > > Are you using Eclipse? If so, you should be able to easily
> create
> > > > patch
> > > > files and apply patch files that Yang (or I) send you. You
should
> > also
> > > > be
> > > > able to debug the code (including into the EMF code) to
understand
> > > where
> > > >
> > > > things are going wrong. Let us know if you need help setting up
an
> > > > effective development environment.
> > > >
> > > > Thanks,
> > > > Frank
> > > >
> > > >
> > > > "Christian Landbo Frederiksen"
> > > <[EMAIL PROTECTED]>
> > > >
> > > > wrote on 02/14/2007 07:46:23 AM:
> > > >
> > > > > Yep those are my 2 problems (at the moment)
> > > > >
> > > > > My problem is that I am looking and debugging in the source
and
> > > can't
> > > > > seem to find out where these things take place.
> > > > >
> > > > > /Chr
> > > > >
> > > > >
> > > > > -----Original Message-----
> > > > > From: Yang ZHONG [mailto:[EMAIL PROTECTED]
> > > > > Sent: 13. februar 2007 23:18
> > > > > To: [email protected]
> > > > > Subject: Re: SDO (Types) Registry
> > > > >
> > > > > Very nice to see you participate, it'll be my pleasure to
assist
> > you
> > > > > through.
> > > > >
> > > > > If I understand correctly, there're two problems:
> > > > >
> > > > > 2-1. propertyX, propertyX1, propertyX11
> > > > >
> > > > > EMF records original element/attribute name from XML schema;
> let's
> > > > call
> > > > > it
> > > > > XML name.
> > > > > XML name local part may be not unique, Java identifier has
> > different
> > > > > syntax, and CodeGen may need some convention, etc,
> > > > > so EMF also assigns unique eCore name to
> > > > properties/EStructuralFeatures.
> > > > >
> > > > > EMF derives eCore name from the XML one, and appending 1s to
> > assure
> > > > > uniqueness,
> > > > > so before addToSortedList/addOrReplaceInSortedList, you may
want
> > to
> > > > > bypass
> > > > > the 1s appending if XML name matches.
> > > > > ExtendedMetaData#getNamespace and ExtendedMetaData#getName can
> > give
> > > > you
> > > > > the
> > > > > XML name.
> > > > >
> > > > > 2-2. null eClass.getEPackage()
> > > > >
> > > > > EMF contains EClass(complex type) and EDataType(simple type)
> into
> > > > > EPackage.
> > > > > Being kicked out of the List by "set" within
> > > addOrReplaceInSortedList
> > > > > will
> > > > > make the EClass/EDataType *not* contained by the EPackage.
> > > > > Let me know if you want me to explain more the difference
> between
> > > > > containment and non-containment.
> > > > > EMF/SDO EPackage may have a cache mapping from name to
> > > > EClass/EDataType,
> > > > > and EMF/SDO EClass/Type may also have a cache mapping from
name
> to
> > > > > EStructuralFeature/Property whose type is EClass/EDataType
used
> by
> > > > code
> > > > > such
> > > > > as createDataObject.
> > > > > You may want to assure those cache are updated accordingly so
> that
> > > the
> > > > > kicked-out EClass/EDataType won't be used since whose
> > getEPackage()
> > > is
> > > > > null.
> > > > >
> > > > >
> > > > > On 2/13/07, Christian Landbo Frederiksen <
> > > > > [EMAIL PROTECTED]> wrote:
> > > > > >
> > > > > > Arghhh just ignore the last one.
> > > > > >
> > > > > > I was testing with different namespaces :(
> > > > > >
> > > > > > I still have the nullpointer!
> > > > > >
> > > > > > Sorry for all the spamming - I'm getting pretty frustrated
> now.
> > I
> > > > > think
> > > > > > I'll go to bed....
> > > > > >
> > > > > > /Chr
> > > > > >
> > > > > >
> > > > > > -----Original Message-----
> > > > > > From: Christian Landbo Frederiksen
> > > > > > [mailto:[EMAIL PROTECTED]
> > > > > > Sent: 13. februar 2007 22:40
> > > > > > To: [email protected]
> > > > > > Subject: RE: SDO (Types) Registry
> > > > > >
> > > > > > Further info:
> > > > > >
> > > > > > If I remove the extensibleNamespaces I added to
XSDHelperImpl
> so
> > > it
> > > > > > again looks like this:
> > > > > >
> > > > > > if (ePackage == null ||
> > > > > > TypeHelperImpl.getBuiltInModels().contains(ePackage))
> > > > > >
> > > > > > The nullpointerexception does not occur but then the
existing
> > > types
> > > > of
> > > > > a
> > > > > > namespace does not seem to respond to changes...
> > > > > >
> > > > > > Ought the extensibleNamespaces change stay in:
> > > > > >
> > > > > > if (extensibleNamespaces || ePackage == null ||
> > > > > > TypeHelperImpl.getBuiltInModels().contains(ePackage))
> > > > > >
> > > > > > /Chr
> > > > > >
> > > > > > -----Original Message-----
> > > > > > From: Christian Landbo Frederiksen
> > > > > > [mailto:[EMAIL PROTECTED]
> > > > > > Sent: 13. februar 2007 21:24
> > > > > > To: [email protected]
> > > > > > Subject: RE: SDO (Types) Registry
> > > > > >
> > > > > > Hi Frank
> > > > > >
> > > > > > I tried adding your code very brute forcely by pulling down
> > > > > > computeEClass and computeEDataType from XSDEcoreBuilder to
> > > > > > SDOXSDEcoreBuilder, giving these two methods new names and
> > calling
> > > > > them
> > > > > > from the already existing computeEClass and computeEDataType
> in
> > > > > > SDOXSDEcoreBuilder. In the two pulled down methods I call
the
> > > > > > addOrReplaceInSortedList instead of addToSortedList.
> > > > > >
> > > > > > When I debug it it seems to do the trick in the
> > > > > addOrReplaceInSortedList
> > > > > > method - but once I run it it fails somehow.
> > > > > >
> > > > > > The XSDHelper.INSTANCE.define method completes fine using
the
> > new
> > > > > code,
> > > > > > but afterward I execute the following (where 'rootElement'
is
> > set
> > > to
> > > > > the
> > > > > > root I seek in the particular invocation):
> > > > > >
> > > > > > DataObject documentDataObject =
> > > > > > DataFactory.INSTANCE.create(namespace, "DocumentRoot");
> > > > > > List documentProperties =
> > > > > > documentDataObject.getInstanceProperties();
> > > > > > Property rootProperty = null;
> > > > > > for (Iterator i =
> > > > > documentProperties.iterator();
> > > > > > i.hasNext();) {
> > > > > > Property p = (Property)
> i.next();
> > > > > > // point 1
> > > > > > if
> > > (rootElement.equals(p.getName()))
> > > > {
> > > > > > rootProperty = p;
> > > > > > continue;
> > > > > > }
> > > > > > }
> > > > > >
> > > > > > if (rootProperty == null) {
> > > > > > throw new
> RuntimeException("FOUND
> > > NO
> > > > > > ROOT");
> > > > > > }
> > > > > >
> > > > > > if (!rootProperty.isContainment()) {
> > > > > > throw new
> RuntimeException("ROOT
> > IS
> > > > NOT
> > > > > > CONTAINMENT: " + rootProperty);
> > > > > > } else {
> > > > > > // point 2
> > > > > > DataObject rootDataObject =
> > > > > > documentDataObject.createDataObject(rootProperty);
> > > > > >
> > > > > > CompositeXmlElement
xmlElement
> =
> > > new
> > > > > > CompositeXmlElement(rootDataObject, rootProperty);
> > > > > >
> handleRootDataObject(xmlElement);
> > > > > > return xmlElement;
> > > > > > }
> > > > > >
> > > > > >
> > > > > > At point 1 I get propertyX, propertyX1, propertyX11 even
with
> > the
> > > > new
> > > > > > code that ought to replace propertyX??
> > > > > >
> > > > > > At point 2 I now get:
> > > > > >
> > > > > > java.lang.NullPointerException
> > > > > > at
> > > org.eclipse.emf.ecore.util.EcoreUtil.create(EcoreUtil.java:2970)
> > > > > > at
> > > > > >
> > > > >
> > > >
> > >
> >
>
org.apache.tuscany.sdo.util.DataObjectUtil.create(DataObjectUtil.java:24
> > > > > > 72)
> > > > > > at
> > > > > >
> > > > >
> > > >
> > >
> >
>
org.apache.tuscany.sdo.util.DataObjectUtil.createDataObject(DataObjectUt
> > > > > > il.java:434)
> > > > > > at
> > > > > >
> > > > >
> > > >
> > >
> >
>
org.apache.tuscany.sdo.util.DataObjectUtil.createDataObject(DataObjectUt
> > > > > > il.java:463)
> > > > > > at
> > > > > >
> > > > >
> > > >
> > >
> >
>
org.apache.tuscany.sdo.impl.DataObjectImpl.createDataObject(DataObjectIm
> > > > > > pl.java:1216)
> > > > > >
> > > > > > Any ideas (if you can interpret this mail)?
> > > > > >
> > > > > > /Chr
> > > > > >
> > > > > > -----Original Message-----
> > > > > > From: Frank Budinsky [mailto:[EMAIL PROTECTED]
> > > > > > Sent: 13. februar 2007 18:23
> > > > > > To: [email protected]
> > > > > > Subject: RE: SDO (Types) Registry
> > > > > >
> > > > > > Hi Christian,
> > > > > >
> > > > > > To replace an existing type, you need to override the
behavior
> > of
> > > > > > XSDEcoreBuilder methods: createEClass() and
createEDataType()
> to
> > > not
> > > > > add
> > > > > > a
> > > > > > duplicate, but instead replace it when found. I noticed that
> > they
> > > > both
> > > > > > call this method to add the new type:
> > > > > >
> > > > > > public static void addToSortedList(List eNamedElements,
> > > > ENamedElement
> > > > > > eNamedElement)
> > > > > > {
> > > > > > int index = Collections.binarySearch(eNamedElements,
> > > > eNamedElement,
> > > > > > Comparator.INSTANCE);
> > > > > > if (index < 0)
> > > > > > {
> > > > > > eNamedElements.add(-(index + 1), eNamedElement);
> > > > > > }
> > > > > > else if (eNamedElements.get(index) != eNamedElement)
> > > > > > {
> > > > > > eNamedElements.add(index, eNamedElement);
> > > > > > }
> > > > > > }
> > > > > >
> > > > > > What you want is to do is something like this instead:
> > > > > >
> > > > > > public static void addOrReplaceInSortedList(List
> > eNamedElements,
> > > > > > ENamedElement eNamedElement)
> > > > > > {
> > > > > > int index = Collections.binarySearch(eNamedElements,
> > > > eNamedElement,
> > > > > > Comparator.INSTANCE);
> > > > > > if (index < 0)
> > > > > > {
> > > > > > eNamedElements.add(-(index + 1), eNamedElement);
> > > > > > }
> > > > > > else if (eNamedElements.get(index) != eNamedElement)
> > > > > > {
> > > > > > eNamedElements.set(index, eNamedElement); // overwrite
> > > existing
> > > > > > element
> > > > > > }
> > > > > > }
> > > > > >
> > > > > > The only question, is how best to optionally turn on this
> > > behavior.
> > > > I
> > > > > > think that adding something like this in SDOXSDEcoreBuilder:
> > > > > >
> > > > > > protected boolean overwrite = false;
> > > > > >
> > > > > > and setting it to true in XSDHelperImpl, when you want this
> > > > behavior.
> > > > > >
> > > > > > Anyway, that's where I'd start. Then you can try to figure
out
> > > where
> > > > > > best
> > > > > > to check the variable and change to the alternate
> > > > > > addOrReplaceInSortedList() behavior.
> > > > > >
> > > > > > Let me know how it goes, and if you have any other
questions.
> > > > > >
> > > > > > Frank.
> > > > > >
> > > > > >
> > > > > > "Christian Landbo Frederiksen"
> > > > > <[EMAIL PROTECTED]>
> > > > > >
> > > > > > wrote on 02/12/2007 03:15:52 PM:
> > > > > >
> > > > > > > Hi Frank et. al.
> > > > > > >
> > > > > > > First I'll summarize my use case as Yang Zhong requested:
> > > > > > >
> > > > > > > An xml schema is uploaded and SDO is used to generate a
form
> > for
> > > > > > > submitting data as xml-instances of the schema.
> > > > > > > New schemas in the same namespace may be added often
> resulting
> > > in
> > > > > new
> > > > > > > forms (this is the first issue where I need to extend
> existing
> > > > > > > namespaces).
> > > > > > >
> > > > > > > Xml instances may later be edited again.
> > > > > > > This is the most common use case and SDO seems to support
> this
> > > > very
> > > > > > > well.
> > > > > > >
> > > > > > > BUT xml schemas may be modified, even individual types.
> > > > > > >
> > > > > > > This of course flagged some warning signs and schema
> versions
> > > were
> > > > > > > considered.
> > > > > > > But 'use at own risk' was chosen because of its
simplicity.
> To
> > > > > support
> > > > > > > this strategy a status/mode will be introduced so
> > xml-instances
> > > > > cannot
> > > > > > > be edited while schema is in 'administration'-mode. This
> ought
> > > to
> > > > > > handle
> > > > > > > the case with instances at schema-modification time.
> > > > > > >
> > > > > > > With regards to serialized xml instances any data that is
> > > rendered
> > > > > > > invalid with type changes will be reset/deleted as of
> design.
> > > > > > >
> > > > > > > I sure like the fact that you say it would not be
difficult
> to
> > > > > > implement
> > > > > > > replacing existing types and I would greatly appreciate
any
> > help
> > > > in
> > > > > > that
> > > > > > > direction.
> > > > > > >
> > > > > > > /Chr
> > > > > > >
> > > > > > >
> > > > > > > -----Original Message-----
> > > > > > > From: Frank Budinsky [mailto:[EMAIL PROTECTED]
> > > > > > > Sent: 12. februar 2007 20:37
> > > > > > > To: [email protected]
> > > > > > > Subject: RE: SDO (Types) Registry
> > > > > > >
> > > > > > > Christian,
> > > > > > >
> > > > > > > I don't think your scenario is beyond the purpose of SDO -
> In
> > > > fact,
> > > > > I
> > > > > > > see
> > > > > > > it as a "real world" example that we should try to
> > accommodate.
> > > > > > >
> > > > > > > To provide an option that allows you to overwrite/replace
> > > existing
> > > > > > > types,
> > > > > > > would not be difficult to do - but it would be dangerous
to
> > use
> > > > if,
> > > > > > for
> > > > > > > example, you have instances of the types at the time you
> > change
> > > > > them.
> > > > > > > Also, you could end up with corrupt models if, for
example,
> > you
> > > > > delete
> > > > > > a
> > > > > > >
> > > > > > > type that is referenced by another. What about serialized
> XML
> > > > > > instances?
> > > > > > >
> > > > > > > If you change a type and then try to load a serialized
XML,
> > > unless
> > > > > the
> > > > > >
> > > > > > > types are a compatible extension (i.e., only new things
> > added),
> > > it
> > > > > may
> > > > > > > no
> > > > > > > longer conform to the schema. What level of versioning
does
> > this
> > > > > > > requirement imply?
> > > > > > >
> > > > > > > Would it be acceptable if this option was a "use at own
> risk"
> > > > > feature
> > > > > > -
> > > > > > > the user needs to be very careful when using it?
> > > > > > >
> > > > > > > I realize that, as an SDO/EMF novice, you may have a hard
> time
> > > > > finding
> > > > > > > the
> > > > > > > right places in the code that need to change, so we can
help
> > > with
> > > > > > that,
> > > > > > > if
> > > > > > > we agree exactly what we're trying to implement.
> > > > > > >
> > > > > > > Frank.
> > > > > > >
> > > > > > > "Christian Landbo Frederiksen"
> > > > > > <[EMAIL PROTECTED]>
> > > > > > >
> > > > > > > wrote on 02/12/2007 01:40:25 PM:
> > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > > Let me first say, I don't not have very much insight
into
> > how
> > > > > > Tuscany
> > > > > > > is
> > > > > > > > built up.
> > > > > > > >
> > > > > > > > I am dealing with a situation where the xsd's, that
define
> > the
> > > > > > format
> > > > > > > of
> > > > > > > > a generic data publishing sysem, can be added and
changed
> > > > > > dynamically
> > > > > > > -
> > > > > > > > even the individual types of a namespace can be changed
> > > > (probably
> > > > > > not
> > > > > > > > very often). I first looked into EMF XSD and then found
> > > Tuscany,
> > > > > and
> > > > > > > it
> > > > > > > > has looked very promising.
> > > > > > > >
> > > > > > > > Except that I ran into the fact that namespaces cannot
be
> > > > altered
> > > > > > once
> > > > > > > > defined. Frank Budinsky came up with a solution where
> > > namespaces
> > > > > can
> > > > > > > be
> > > > > > > > extended, but the types that exist already in a
namespace
> > > cannot
> > > > > be
> > > > > > > > redefined.
> > > > > > > >
> > > > > > > > Perhaps this scenario is way beyond the purpose of SDO,
> but
> > > > > besides
> > > > > > > > these two issues I find it very useful to work with
> runtime
> > > xml
> > > > > > > schemas.
> > > > > > > >
> > > > > > > > So as you might guess I think an option to totally
> redefine
> > > > > > namespaces
> > > > > > > > or to extend them with new types and just overwrite the
> > > existing
> > > > > > ones,
> > > > > > > > would be fine.
> > > > > > > >
> > > > > > > > This is in fact something I am trying to look into
> implement
> > > > > myself,
> > > > > > > but
> > > > > > > > at the understanding I'm at now I am having difficulties
> > > > > maneuvering
> > > > > > > in
> > > > > > > > the EMF. I have no idea where defined schemas are
> currently
> > > kept
> > > > > in
> > > > > > > the
> > > > > > > > VM and therefore don't know where to put in the code to
> > allow
> > > > > types
> > > > > > of
> > > > > > > a
> > > > > > > > namespace to be redefined.
> > > > > > > >
> > > > > > > > Any pointers to where this code would go would be
GREAT...
> > > > > > > >
> > > > > > > > /Chr
> > > > > > > >
> > > > > > > > -----Original Message-----
> > > > > > > > From: kelvin goodson [mailto:[EMAIL PROTECTED]
> > > > > > > > Sent: 10. februar 2007 13:27
> > > > > > > > To: [email protected]
> > > > > > > > Subject: Re: SDO (Types) Registry
> > > > > > > >
> > > > > > > > Christian,
> > > > > > > >
> > > > > > > > unfortunately not. The only open JIRA we have in this
> > area
> > > is
> > > > > > > > http://issues.apache.org/jira/browse/TUSCANY-761 for
> > > > unregistering
> > > > > > all
> > > > > > > > the
> > > > > > > > types in a namespace. Perhaps we could collect together
> > some
> > > > info
> > > > > > on
> > > > > > > > what's
> > > > > > > > really useful here and have some design discussions on
how
> > to
> > > > > handle
> > > > > > > > type
> > > > > > > > lifecycle. There have previously been discussions on
> > forming
> > > > > > > > associations
> > > > > > > > between HelperContexts so that one HC can have
> dependencies
> > > on
> > > > > > > > another/others. This might allow for example dropping
> type
> > > > > > > definitions
> > > > > > > > by
> > > > > > > > dropping all references to a given HelperContext. It
> would
> > be
> > > > > good
> > > > > > to
> > > > > > > > know
> > > > > > > > exactly which operations would be the most valuable to
you
> > in
> > > > > order
> > > > > > to
> > > > > > > > help
> > > > > > > > make good design decisions.
> > > > > > > >
> > > > > > > > Regards, Kelvin.
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > > On 10/02/07, Christian Landbo Frederiksen <
> > > > > > > > [EMAIL PROTECTED]> wrote:
> > > > > > > > >
> > > > > > > > > Is there no way to 'undefine' types if you have to
> modify
> > > > > existing
> > > > > > > > types?
> > > > > > > > >
> > > > > > > > > /Chr
> > > > > > > > >
> > > > > > > > > ________________________________
> > > > > > > > >
> > > > > > > > > From: Frank Budinsky [mailto:[EMAIL PROTECTED]
> > > > > > > > > Sent: Fri 2/9/2007 5:10 PM
> > > > > > > > > To: [email protected]
> > > > > > > > > Subject: RE: SDO (Types) Registry
> > > > > > > > >
> > > > > > > > >
> > > > > > > > >
> > > > > > > > > If the requirement is just to add new types to a
> > namespace,
> > > as
> > > > > > > opposed
> > > > > > > > to
> > > > > > > > > modifying existing types (which is nasty), I don't
think
> > it
> > > > > would
> > > > > > be
> > > > > > > > hard
> > > > > > > > > to add this support.
> > > > > > > > >
> > > > > > > > > This is open source, maybe you want to help :-)
> > > > > > > > >
> > > > > > > > > Initially, I would suggest adding a new instance
> variable
> > in
> > > > > > > > XSDHelperImpl
> > > > > > > > > - extensibleNamespaces (false by default, but can be
set
> > to
> > > > > true)
> > > > > > -
> > > > > > > > and
> > > > > > > > > then change this line in XSDHelperImpl.define():
> > > > > > > > >
> > > > > > > > > if (ePackage == null ||
> > > > TypeHelperImpl.getBuiltInModels
> > > > > > > > > ().contains(ePackage))
> > > > > > > > >
> > > > > > > > > to this:
> > > > > > > > >
> > > > > > > > > if (extensibleNamespaces || ePackage == null
||
> > > > > > > > TypeHelperImpl.
> > > > > > > > > getBuiltInModels().contains(ePackage))
> > > > > > > > >
> > > > > > > > > Then, it's a matter of debugging to make sure that in
> > > > > > > > SDOXSDEcoreBuilder,
> > > > > > > > > when a type is requested that already exists, it just
> uses
> > > the
> > > > > > > > existing
> > > > > > > > > type and moves on. New types would get added in the
> usual
> > > way.
> > > > > > > > >
> > > > > > > > > I think this may be related to, and helped by, the
work
> > that
> > > > > will
> > > > > > be
> > > > > > > > done
> > > > > > > > > in TUSCANY-1085 (not the patch provided by Fuhwei, but
> the
> > > > > proper
> > > > > > > fix
> > > > > > > > that
> > > > > > > > > needs to be done), which needs to ensure that
previously
> > > > loaded
> > > > > > > types
> > > > > > > > are
> > > > > > > > > found in SDOXSDEcoreBuilder.
> > > > > > > > >
> > > > > > > > > Frank.
> > > > > > > > >
> > > > > > > > >
> > > > > > > > > "Christian Landbo Frederiksen"
> > > > > > > > <[EMAIL PROTECTED]>
> > > > > > > > > wrote on 02/09/2007 08:36:35 AM:
> > > > > > > > >
> > > > > > > > > > Hmmm. I just found this in the Dev list:
> > > > > > > > > >
> > > > > > > > > > "In the future, we may want to look at allowing new
> > types
> > > to
> > > > > be
> > > > > > > > added to
> > > > > > > > > > an
> > > > > > > > > > existing namespace, but currently that is not
> > supported."
> > > -
> > > > > > Frank
> > > > > > > > > > Budinsky
> > > > > > > > > >
> > > > > > > > > > If this is not coming up real soon - is there a way
to
> > > > > > circumvent
> > > > > > > > this
> > > > > > > > > > using the underlying EMF or something?
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > > -----Original Message-----
> > > > > > > > > > From: Christian Landbo Frederiksen
> > > > > > > > > > [mailto:[EMAIL PROTECTED]
> > > > > > > > > > Sent: 9. februar 2007 14:29
> > > > > > > > > > To: [email protected]
> > > > > > > > > > Subject: RE: SDO (Types) Registry
> > > > > > > > > >
> > > > > > > > > > And then again - that way I can't define from my
xsd.
> > > > > > > > > >
> > > > > > > > > > Dang. How do I solve this?
> > > > > > > > > >
> > > > > > > > > > /Chr
> > > > > > > > > >
> > > > > > > > > > -----Original Message-----
> > > > > > > > > > From: Christian Landbo Frederiksen
> > > > > > > > > > [mailto:[EMAIL PROTECTED]
> > > > > > > > > > Sent: 9. februar 2007 14:27
> > > > > > > > > > To: [email protected]
> > > > > > > > > > Subject: RE: SDO (Types) Registry
> > > > > > > > > >
> > > > > > > > > > I have just run into calling define(...) for a
schema
> > with
> > > > > > > namespace
> > > > > > > > > > that has already been defined by another schema does
> NOT
> > > add
> > > > > the
> > > > > > > > types
> > > > > > > > > > from the new schema.
> > > > > > > > > >
> > > > > > > > > > I suppose I have to register each seperately on its
> own
> > > > > > > typehelper?
> > > > > > > > > >
> > > > > > > > > > Is there a way to see if a namespace is already
> defined?
> > > > > > > > > >
> > > > > > > > > > /Chr
> > > > > > > > > >
> > > > > > > > > > -----Original Message-----
> > > > > > > > > > From: Yang ZHONG
[mailto:[EMAIL PROTECTED]
> > > > > > > > > > Sent: 27. januar 2007 20:15
> > > > > > > > > > To: [email protected]
> > > > > > > > > > Subject: Re: SDO (Types) Registry
> > > > > > > > > >
> > > > > > > > > > SDO spec seems not addressing the issues yet, here's
> > what
> > > I
> > > > > know
> > > > > > > for
> > > > > > > > > > Tuscany
> > > > > > > > > > implementation.
> > > > > > > > > >
> > > > > > > > > > 1. connection between XSDHelper#define and
> > XMLHelper#load
> > > > > > > > > > The assumption is right: XSDHelper#define stores
> Types
> > > > into
> > > > > > > > > > (Package/Types) Registry and XMLHelper#load uses the
> > Types
> > > > > from
> > > > > > > > > > the (Package/Types) Registry
> > > > > > > > > >
> > > > > > > > > > 2. How XMLHelper#load uses Types
> > > > > > > > > > Assuming a XML:
> > > > > > > > > > <root:stock xmlns:root="NS" ...
> > > > > > > > > > XMLHelper#load looks for the Type of the global
> > Property
> > > > > with
> > > > > > > > > > NameSpace
> > > > > > > > > > "NS" and name "stock", and uses the Type to create
> > > > DataObject
> > > > > > > > instance
> > > > > > > > > > then
> > > > > > > > > > loads the rest of the XML.
> > > > > > > > > > The Type can be dynamic from XSDHelper#define,
where
> > the
> > > > > > > > DataObject is
> > > > > > > > > > an
> > > > > > > > > > instance of DataObjectImpl.
> > > > > > > > > > The Type can also be static from code generation,
> > where
> > > > the
> > > > > > > > DataObject
> > > > > > > > > > is
> > > > > > > > > > an instance of generated class such as MyStock.
> > > > > > > > > > If no Type available, XMLHelper#load creates an
> > instance
> > > > of
> > > > > > > > > > AnyTypeDataObject and loads data without any
metadata.
> > > > > > > > > >
> > > > > > > > > > 3. (Package/Types) Registry Garbage Collection
> > > > > > > > > > Types are weakly referenced by ClassLoader. If a
> > (J2EE)
> > > > > > > > application
> > > > > > > > > > stops,
> > > > > > > > > > Types can be Garbage Collected unless a system
library
> > > (live
> > > > > > > > > > ClassLoader)
> > > > > > > > > > holds a strong reference.
> > > > > > > > > >
> > > > > > > > > > 4. (Package/Types) Registry Thread Safety
> > > > > > > > > > No Thread Safety for the moment. However it could
be
> > > done;
> > > > > the
> > > > > > > > > > previous
> > > > > > > > > > SDO implementation I worked on supports Thread
Safety
> > for
> > > > > > example.
> > > > > > > > > >
> > > > > > > > > > 5. Two XSDHelper#define for same XSD(s)
> > > > > > > > > > The later one overwrites the earlier one if same
> > > > > > > > > > scope/application/ClassLoader. If concurrent, slower
> > > thread
> > > > > > "wins"
> > > > > > > > :-)
> > > > > > > > > > If different scope/application/ClassLoader,
multiple
> > > > copies
> > > > > > for
> > > > > > > > the
> > > > > > > > > > moment. However it could be optimized to save both
> > storage
> > > > and
> > > > > > > > > > defining/loading time; the previous SDO
implementation
> I
> > > > > worked
> > > > > > on
> > > > > > > > > > defines/loads same XSD(s) only once if no
modification
> > and
> > > > > makes
> > > > > > > > Types
> > > > > > > > > > available to multiple
> scopes/applications/ClassLoaders,
> > > for
> > > > > > > example.
> > > > > > > > > >
> > > > > > > > > > On 1/27/07, Christian Landbo Frederiksen <
> > > > > > > > > > [EMAIL PROTECTED]> wrote:
> > > > > > > > > > >
> > > > > > > > > > > I was wondering what goes on in the background,
> since
> > > SDO
> > > > > can
> > > > > > be
> > > > > > > > used
> > > > > > > > > > > the way is is used.
> > > > > > > > > > >
> > > > > > > > > > > In the example:
> > > > > > > > > > >
> > > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
>
org.apache.tuscany.samples.sdo.specCodeSnippets.CreateDataObjectFromXsdA
> > > > > > > > > > > ndXmlFiles
> > > > > > > > > > >
> > > > > > > > > > > types are defined in one static method like this:
> > > > > > > > > > > XSDHelper.INSTANCE.define(is, null);
> > > > > > > > > > >
> > > > > > > > > > > and then in another static method xml is loaded:
> > > > XMLDocument
> > > > > > > > xmlDoc =
> > > > > > > > > > > XMLHelper.INSTANCE.load(is);
> > > > > > > > > > >
> > > > > > > > > > > What is the connection between these two separate
> > method
> > > > > > > > invocations?
> > > > > > > > > > > How does the loading of xml use the types defined
> > above?
> > > I
> > > > > > > assume
> > > > > > > > > > > something is stored somewhere but how does this
> relate
> > > to
> > > > > > > garbage
> > > > > > > > > > > collection and thread safety? I meas somebody
could
> > call
> > > > > > > > > > > XSDHelper.INSTANCE.define(is, null); with another
> xsd
> > > > > > somewhere
> > > > > > > > else
> > > > > > > > > > in
> > > > > > > > > > > the same VM?
> > > > > > > > > > >
> > > > > > > > > > > /Chr
> > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > > --
> > > > > > > > > >
> > > > > > > > > > Yang ZHONG
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > >
> > > > > >
> > > >
> >
---------------------------------------------------------------------
> > > > > > > > > > To unsubscribe, e-mail:
> > > > [EMAIL PROTECTED]
> > > > > > > > > > For additional commands, e-mail:
> > > > > [EMAIL PROTECTED]
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > >
> > > > > >
> > > >
> >
---------------------------------------------------------------------
> > > > > > > > > > To unsubscribe, e-mail:
> > > > [EMAIL PROTECTED]
> > > > > > > > > > For additional commands, e-mail:
> > > > > [EMAIL PROTECTED]
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > >
> > > > > >
> > > >
> >
---------------------------------------------------------------------
> > > > > > > > > > To unsubscribe, e-mail:
> > > > [EMAIL PROTECTED]
> > > > > > > > > > For additional commands, e-mail:
> > > > > [EMAIL PROTECTED]
> > > > > > > > > >
> > > > > > > > >
> > > > > > > > >
> > > > > > > > >
> > > > > > >
> > > > >
> > >
> ---------------------------------------------------------------------
> > > > > > > > > To unsubscribe, e-mail:
> > > [EMAIL PROTECTED]
> > > > > > > > > For additional commands, e-mail:
> > > > [EMAIL PROTECTED]
> > > > > > > > >
> > > > > > > > >
> > > > > > > > >
> > > > > > > > >
> > > > > > > > >
> > > > > > > > >
> > > > > > > > >
> > > > > > >
> > > > >
> > >
> ---------------------------------------------------------------------
> > > > > > > > > To unsubscribe, e-mail:
> > > [EMAIL PROTECTED]
> > > > > > > > > For additional commands, e-mail:
> > > > [EMAIL PROTECTED]
> > > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > >
> > > >
> >
---------------------------------------------------------------------
> > > > > > > > To unsubscribe, e-mail:
> > [EMAIL PROTECTED]
> > > > > > > > For additional commands, e-mail:
> > > [EMAIL PROTECTED]
> > > > > > > >
> > > > > > >
> > > > > > >
> > > > > > >
> > > > >
> > >
> ---------------------------------------------------------------------
> > > > > > > To unsubscribe, e-mail:
> [EMAIL PROTECTED]
> > > > > > > For additional commands, e-mail:
> > [EMAIL PROTECTED]
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > >
> > > > >
> > >
> ---------------------------------------------------------------------
> > > > > > > To unsubscribe, e-mail:
> [EMAIL PROTECTED]
> > > > > > > For additional commands, e-mail:
> > [EMAIL PROTECTED]
> > > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > >
> >
---------------------------------------------------------------------
> > > > > > To unsubscribe, e-mail:
[EMAIL PROTECTED]
> > > > > > For additional commands, e-mail:
> [EMAIL PROTECTED]
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > >
> >
---------------------------------------------------------------------
> > > > > > To unsubscribe, e-mail:
[EMAIL PROTECTED]
> > > > > > For additional commands, e-mail:
> [EMAIL PROTECTED]
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > >
> >
---------------------------------------------------------------------
> > > > > > To unsubscribe, e-mail:
[EMAIL PROTECTED]
> > > > > > For additional commands, e-mail:
> [EMAIL PROTECTED]
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > >
> >
---------------------------------------------------------------------
> > > > > > To unsubscribe, e-mail:
[EMAIL PROTECTED]
> > > > > > For additional commands, e-mail:
> [EMAIL PROTECTED]
> > > > > >
> > > > > >
> > > > >
> > > > >
> > > > > --
> > > > >
> > > > > Yang ZHONG
> > > > >
> > > > >
> > >
> ---------------------------------------------------------------------
> > > > > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > > > > For additional commands, e-mail:
[EMAIL PROTECTED]
> > > > >
> > > >
> > > >
> > > >
> >
---------------------------------------------------------------------
> > > > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > > > For additional commands, e-mail: [EMAIL PROTECTED]
> > > >
> > > >
> > > >
> > > >
> >
---------------------------------------------------------------------
> > > > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > > > For additional commands, e-mail: [EMAIL PROTECTED]
> > > >
> > > >
> > > >
> > > >
> > > >
> > > > -----------------------------------------
> > > > CONFIDENTIALITY STATEMENT:
> > > > This e-mail transmission contains information that is intended
to
> > > > be confidential. It is intended only for the addressee named
> > > > above. If you receive this e-mail in error, please do not read,
> > > > copy, or disseminate it. If you are not the intended recipient,
> > > > any disclosure, copying, distribution or use of the contents of
> > > > this information is prohibited. Please reply to the message
> > > > immediately by informing the sender that the message was
> > > > misdirected. After replying, please erase it from your computer
> > > > system. Your assistance in correcting this error is
appreciated.
> > > >
> > > >
> >
---------------------------------------------------------------------
> > > > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > > > For additional commands, e-mail: [EMAIL PROTECTED]
> > > >
> > > >
> > >
> > >
> ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > > For additional commands, e-mail: [EMAIL PROTECTED]
> > >
> >
> >
> >
---------------------------------------------------------------------
> > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > For additional commands, e-mail: [EMAIL PROTECTED]
> >
> >
> >
> >
---------------------------------------------------------------------
> > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > For additional commands, e-mail: [EMAIL PROTECTED]
> >
> >
> >
> >
---------------------------------------------------------------------
> > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > For additional commands, e-mail: [EMAIL PROTECTED]
> >
> >
>
>
> --
>
> Yang ZHONG
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>
--
Yang ZHONG
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
