[jira] Commented: (TUSCANY-1113) Extensible namespaces and types that change

["Christian Landbo Frederiksen (JIRA)" <tu...@ws.apache.org>]

    [ https://issues.apache.org/jira/browse/TUSCANY-1113?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12473177 ] 

Christian Landbo Frederiksen commented on TUSCANY-1113:
-------------------------------------------------------

Reading a response from Frank Budinsky, I realized that the issues are probably solved with the 2 fixes.
Adding or replacing individual properties in a single type is not necessary when you can redefine an entire type.

SO changing TestTypeChangesAndExtensibleNamespaces.generate to just:

XSDHelper.INSTANCE.define(new String(xsdFile.getBytes("UTF-8")));
DataObject documentDataObject = DataFactory.INSTANCE.create(namespace, rootElement+"Type");
handleRootDataObject(documentDataObject);

Actually makes the program work!

Frank's answer:

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.


> Extensible namespaces and types that change
> -------------------------------------------
>
>                 Key: TUSCANY-1113
>                 URL: https://issues.apache.org/jira/browse/TUSCANY-1113
>             Project: Tuscany
>          Issue Type: Improvement
>          Components: Java SDO Implementation
>         Environment: Eclipse, EMF 2.2.1
>            Reporter: Christian Landbo Frederiksen
>         Attachments: SDOXSDEcoreBuilder.java, TestTypeChangesAndExtensibleNamespaces.java, XSDHelperImpl.java
>
>
> Once an xml-schema with a namespace is defined (XSDHelper) you cannot define other schemas with the same namespace.
> I would like namespaces to be extensible.
> Once the types of a schema is defined you cannot change them by defining an altered version of the schema.
> I realize the dangers of modifying already defined types but I believe i ought to be an option.
> Summary from: http://www.mail-archive.com/tuscany-user%40ws.apache.org/msg00624.html
> 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. 

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org