You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tuscany.apache.org by "Fuhwei Lwo (JIRA)" <tu...@ws.apache.org> on 2007/01/31 20:40:05 UTC
[jira] Created: (TUSCANY-1085) schemaLocation attribute in the
should be only a hint
schemaLocation attribute in the <xsd:import> should be only a hint
------------------------------------------------------------------
Key: TUSCANY-1085
URL: https://issues.apache.org/jira/browse/TUSCANY-1085
Project: Tuscany
Issue Type: Bug
Components: Java SDO Implementation
Affects Versions: Cpp-M3
Reporter: Fuhwei Lwo
Fix For: Java-SDO-Mx
Currently XSDHelper.define(InputStream inputStream, String schemaLocation) uses the second parameter to locate the importing XSD specified by the schemaLocation attribute. If the schemaLocation is incorrect, its whole namespace cannot be resolved.
The SDO runtime should be able to look up the registered namespace and type even the xsd:import failed. Also, the users should be able to register their SDO types with their XSD referencing the sdoModel.xsd but without providing sdoModel.xsd in their applications because sdoModel.xsd is the SDO core model.
I will attach a test case later.
--
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
[jira] Commented: (TUSCANY-1085) schemaLocation attribute in the
should be only a hint
Posted by "Kelvin Goodson (JIRA)" <tu...@ws.apache.org>.
[ https://issues.apache.org/jira/browse/TUSCANY-1085?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12471681 ]
Kelvin Goodson commented on TUSCANY-1085:
-----------------------------------------
Hi Fuhwei,
I was a bit worried by the big override method in your patch, so I have taken a good long look at this, but as its an area of the code I'm not very familiar with I can't necessarily jump in with an expert comment. My current analysis of this is that EMF forces an assumption in the two lines of XSDEcoreBuilder's createFeature method
XSDTypeDefinition elementTypeDefinition = getEffectiveTypeDefinition(xsdComponent, xsdElementDeclaration);
EClassifier eClassifier = getEClassifier(elementTypeDefinition);
that the type of an element is contained in the emf representation generated from the input schema. So, if we could override getEffectiveTypeDefinition and conditionally return an XSDTypeDefinition from the metadata available within our SDO scope then we would be OK.
For the case where the type referenced in the schema was provided by an earlier XSD to SDO conversion I think we can retrieve this data, and then do whatever's necessary, if anything, to get the EClassifier based on that type definition (I haven't spent the time to dig into that as I thought now was a good time to discuss)
This wouldn't cover the case where a schema writer was assuming some types were available that hadn't been produced from an XSD, but I don't know that that's currently a realistic use case. If my analysis is correct we could lobby EMF to make a change so that the above two lines were incorporated into a single protected method call that didn't require the EClassifier lookup to proceed via an XSDTypeDefinition instance. Then our override would be able to return an EClassifier based on the xsdComponent and xsdElementDeclaration directly.
What do you think? Have I missed a/the point here?
> schemaLocation attribute in the <xsd:import> should be only a hint
> ------------------------------------------------------------------
>
> Key: TUSCANY-1085
> URL: https://issues.apache.org/jira/browse/TUSCANY-1085
> Project: Tuscany
> Issue Type: Bug
> Components: Java SDO Implementation
> Affects Versions: Java-SDO-Mx
> Reporter: Fuhwei Lwo
> Fix For: Java-SDO-Mx
>
> Attachments: org.apache.tuscany.sdo.test.SimpleDynamicTestCase.txt, patch-1085.1, simple2.xsd, simple2.xsd, SimpleDynamicTestCase.java
>
>
> Currently XSDHelper.define(InputStream inputStream, String schemaLocation) uses the second parameter to locate the importing XSD specified by the schemaLocation attribute. If the schemaLocation is incorrect, its whole namespace cannot be resolved.
> The SDO runtime should be able to look up the registered namespace and type even the xsd:import failed. Also, the users should be able to register their SDO types with their XSD referencing the sdoModel.xsd but without providing sdoModel.xsd in their applications because sdoModel.xsd is the SDO core model.
> I will attach a test case later.
--
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
[jira] Updated: (TUSCANY-1085) schemaLocation attribute in the
should be only a hint
Posted by "Fuhwei Lwo (JIRA)" <tu...@ws.apache.org>.
[ https://issues.apache.org/jira/browse/TUSCANY-1085?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Fuhwei Lwo updated TUSCANY-1085:
--------------------------------
Attachment: patch-1085.1
I have attached a new copy of simple2.xsd and patch-1085.1 as my first try of fixing this problem.
I have left "FHL" in the patch to indicate what I have changed. Basically, I changed SDOXSDEcoreBuilder.java to look up types with their namespaces against extendedMetaData instead from XSD information. Also, createFeature() was changed to return the property with correct containment value if the XSD type cannot be resolved which becomes XSDSimpleTypeDefinition.
This fix has passed all the SDO impl test cases. Unfortunately, there is more work to do because the serialization doesn't serialize the correct namespace prefix and uri.
Please feel free to review my code and jump in to help. Thanks.
> schemaLocation attribute in the <xsd:import> should be only a hint
> ------------------------------------------------------------------
>
> Key: TUSCANY-1085
> URL: https://issues.apache.org/jira/browse/TUSCANY-1085
> Project: Tuscany
> Issue Type: Bug
> Components: Java SDO Implementation
> Affects Versions: Java-SDO-Mx
> Reporter: Fuhwei Lwo
> Fix For: Java-SDO-Mx
>
> Attachments: org.apache.tuscany.sdo.test.SimpleDynamicTestCase.txt, patch-1085.1, simple2.xsd, simple2.xsd, SimpleDynamicTestCase.java
>
>
> Currently XSDHelper.define(InputStream inputStream, String schemaLocation) uses the second parameter to locate the importing XSD specified by the schemaLocation attribute. If the schemaLocation is incorrect, its whole namespace cannot be resolved.
> The SDO runtime should be able to look up the registered namespace and type even the xsd:import failed. Also, the users should be able to register their SDO types with their XSD referencing the sdoModel.xsd but without providing sdoModel.xsd in their applications because sdoModel.xsd is the SDO core model.
> I will attach a test case later.
--
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
[jira] Commented: (TUSCANY-1085) schemaLocation attribute in the
should be only a hint
Posted by "Kelvin Goodson (JIRA)" <tu...@ws.apache.org>.
[ https://issues.apache.org/jira/browse/TUSCANY-1085?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12472279 ]
Kelvin Goodson commented on TUSCANY-1085:
-----------------------------------------
Hi Fuhwei,
I think I have the basis of a more concise fix, but I would like to hand it back to you as I have been looking at this for a long time
If SDOXSDEcoreBuilder's getEClassifier method is changed to ....
public EClassifier getEClassifier(XSDTypeDefinition xsdTypeDefinition) {
EClassifier eClassifier = null;
if (rootSchema.getSchemaForSchemaNamespace().equals(xsdTypeDefinition.getTargetNamespace())) {
eClassifier =
getBuiltInEClassifier(
xsdTypeDefinition.getURI(),
xsdTypeDefinition.getName());
} else {
EPackage pkg = extendedMetaData.getPackage(xsdTypeDefinition.getTargetNamespace());
if(pkg != null) {
eClassifier = pkg.getEClassifier(xsdTypeDefinition.getName());
}
if(eClassifier == null ) {
eClassifier = super.getEClassifier(xsdTypeDefinition);
}
}
return eClassifier;
}
then I think there can be some fix up on the fact that the quotes feature is not a containment feature by some state analysis after XSDEcoreBuilder has create the feature in SDOXSDEcoreBuilder's createFeature method
protected EStructuralFeature createFeature(EClass eClass, String name, EClassifier type, XSDComponent xsdComponent, int minOccurs, int maxOccurs) {
EStructuralFeature feature =
super.createFeature(eClass, name, type, xsdComponent, minOccurs, maxOccurs);
XSDTypeDefinition elementTypeDefinition = getEffectiveTypeDefinition(xsdComponent, xsdElementDeclaration);
EClassifier eClassifier = getEClassifier(elementTypeDefinition);
if(elementTypeDefinition instanceof XSDSimpleTypeDefinition && eClassifier instanceof EClass) {
feature.setContainment(true);
}
.........
I have not verified that this state test alone always implies this action, there may be more things to add to the condition before fixing up, but I think it is possible to unambiguously detect this situation and then tweak the containment value. This would be a much smaller fix , can you take a look at this please?
> schemaLocation attribute in the <xsd:import> should be only a hint
> ------------------------------------------------------------------
>
> Key: TUSCANY-1085
> URL: https://issues.apache.org/jira/browse/TUSCANY-1085
> Project: Tuscany
> Issue Type: Bug
> Components: Java SDO Implementation
> Affects Versions: Java-SDO-Mx
> Reporter: Fuhwei Lwo
> Fix For: Java-SDO-Mx
>
> Attachments: org.apache.tuscany.sdo.test.SimpleDynamicTestCase.txt, patch-1085.1, simple2.xsd, simple2.xsd, SimpleDynamicTestCase.java
>
>
> Currently XSDHelper.define(InputStream inputStream, String schemaLocation) uses the second parameter to locate the importing XSD specified by the schemaLocation attribute. If the schemaLocation is incorrect, its whole namespace cannot be resolved.
> The SDO runtime should be able to look up the registered namespace and type even the xsd:import failed. Also, the users should be able to register their SDO types with their XSD referencing the sdoModel.xsd but without providing sdoModel.xsd in their applications because sdoModel.xsd is the SDO core model.
> I will attach a test case later.
--
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
[jira] Commented: (TUSCANY-1085) schemaLocation attribute in the
should be only a hint
Posted by "Kelvin Goodson (JIRA)" <tu...@ws.apache.org>.
[ https://issues.apache.org/jira/browse/TUSCANY-1085?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12472341 ]
Kelvin Goodson commented on TUSCANY-1085:
-----------------------------------------
Resolved at revision 506537
> schemaLocation attribute in the <xsd:import> should be only a hint
> ------------------------------------------------------------------
>
> Key: TUSCANY-1085
> URL: https://issues.apache.org/jira/browse/TUSCANY-1085
> Project: Tuscany
> Issue Type: Bug
> Components: Java SDO Implementation
> Affects Versions: Java-SDO-Mx
> Reporter: Fuhwei Lwo
> Fix For: Java-SDO-Mx
>
> Attachments: org.apache.tuscany.sdo.test.SimpleDynamicTestCase.txt, patch-1085.1, simple2.xsd, simple2.xsd, SimpleDynamicTestCase.java, tuscany-1085.patch2
>
>
> Currently XSDHelper.define(InputStream inputStream, String schemaLocation) uses the second parameter to locate the importing XSD specified by the schemaLocation attribute. If the schemaLocation is incorrect, its whole namespace cannot be resolved.
> The SDO runtime should be able to look up the registered namespace and type even the xsd:import failed. Also, the users should be able to register their SDO types with their XSD referencing the sdoModel.xsd but without providing sdoModel.xsd in their applications because sdoModel.xsd is the SDO core model.
> I will attach a test case later.
--
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
[jira] Updated: (TUSCANY-1085) schemaLocation attribute in the
should be only a hint
Posted by "Fuhwei Lwo (JIRA)" <tu...@ws.apache.org>.
[ https://issues.apache.org/jira/browse/TUSCANY-1085?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Fuhwei Lwo updated TUSCANY-1085:
--------------------------------
Attachment: tuscany-1085.patch2
Hi Kevin,
You were right that your approach would work too though I need to touch up a little. tuscany-1085.patch2 now contains your suggested fixes on SDOXSDEcoreBuilder.java. Thanks.
> schemaLocation attribute in the <xsd:import> should be only a hint
> ------------------------------------------------------------------
>
> Key: TUSCANY-1085
> URL: https://issues.apache.org/jira/browse/TUSCANY-1085
> Project: Tuscany
> Issue Type: Bug
> Components: Java SDO Implementation
> Affects Versions: Java-SDO-Mx
> Reporter: Fuhwei Lwo
> Fix For: Java-SDO-Mx
>
> Attachments: org.apache.tuscany.sdo.test.SimpleDynamicTestCase.txt, patch-1085.1, simple2.xsd, simple2.xsd, SimpleDynamicTestCase.java, tuscany-1085.patch2
>
>
> Currently XSDHelper.define(InputStream inputStream, String schemaLocation) uses the second parameter to locate the importing XSD specified by the schemaLocation attribute. If the schemaLocation is incorrect, its whole namespace cannot be resolved.
> The SDO runtime should be able to look up the registered namespace and type even the xsd:import failed. Also, the users should be able to register their SDO types with their XSD referencing the sdoModel.xsd but without providing sdoModel.xsd in their applications because sdoModel.xsd is the SDO core model.
> I will attach a test case later.
--
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
[jira] Updated: (TUSCANY-1085) schemaLocation attribute in the
should be only a hint
Posted by "Fuhwei Lwo (JIRA)" <tu...@ws.apache.org>.
[ https://issues.apache.org/jira/browse/TUSCANY-1085?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Fuhwei Lwo updated TUSCANY-1085:
--------------------------------
Affects Version/s: (was: Cpp-M3)
Java-SDO-Mx
> schemaLocation attribute in the <xsd:import> should be only a hint
> ------------------------------------------------------------------
>
> Key: TUSCANY-1085
> URL: https://issues.apache.org/jira/browse/TUSCANY-1085
> Project: Tuscany
> Issue Type: Bug
> Components: Java SDO Implementation
> Affects Versions: Java-SDO-Mx
> Reporter: Fuhwei Lwo
> Fix For: Java-SDO-Mx
>
> Attachments: org.apache.tuscany.sdo.test.SimpleDynamicTestCase.txt, simple2.xsd, SimpleDynamicTestCase.java
>
>
> Currently XSDHelper.define(InputStream inputStream, String schemaLocation) uses the second parameter to locate the importing XSD specified by the schemaLocation attribute. If the schemaLocation is incorrect, its whole namespace cannot be resolved.
> The SDO runtime should be able to look up the registered namespace and type even the xsd:import failed. Also, the users should be able to register their SDO types with their XSD referencing the sdoModel.xsd but without providing sdoModel.xsd in their applications because sdoModel.xsd is the SDO core model.
> I will attach a test case later.
--
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
[jira] Updated: (TUSCANY-1085) schemaLocation attribute in the
should be only a hint
Posted by "Fuhwei Lwo (JIRA)" <tu...@ws.apache.org>.
[ https://issues.apache.org/jira/browse/TUSCANY-1085?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Fuhwei Lwo updated TUSCANY-1085:
--------------------------------
Attachment: simple2.xsd
> schemaLocation attribute in the <xsd:import> should be only a hint
> ------------------------------------------------------------------
>
> Key: TUSCANY-1085
> URL: https://issues.apache.org/jira/browse/TUSCANY-1085
> Project: Tuscany
> Issue Type: Bug
> Components: Java SDO Implementation
> Affects Versions: Java-SDO-Mx
> Reporter: Fuhwei Lwo
> Fix For: Java-SDO-Mx
>
> Attachments: org.apache.tuscany.sdo.test.SimpleDynamicTestCase.txt, simple2.xsd, simple2.xsd, SimpleDynamicTestCase.java
>
>
> Currently XSDHelper.define(InputStream inputStream, String schemaLocation) uses the second parameter to locate the importing XSD specified by the schemaLocation attribute. If the schemaLocation is incorrect, its whole namespace cannot be resolved.
> The SDO runtime should be able to look up the registered namespace and type even the xsd:import failed. Also, the users should be able to register their SDO types with their XSD referencing the sdoModel.xsd but without providing sdoModel.xsd in their applications because sdoModel.xsd is the SDO core model.
> I will attach a test case later.
--
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
[jira] Updated: (TUSCANY-1085) schemaLocation attribute in the
should be only a hint
Posted by "Kelvin Goodson (JIRA)" <tu...@ws.apache.org>.
[ https://issues.apache.org/jira/browse/TUSCANY-1085?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Kelvin Goodson updated TUSCANY-1085:
------------------------------------
Fix Version/s: (was: Java-SDO-Mx)
Java-SDO-M3
> schemaLocation attribute in the <xsd:import> should be only a hint
> ------------------------------------------------------------------
>
> Key: TUSCANY-1085
> URL: https://issues.apache.org/jira/browse/TUSCANY-1085
> Project: Tuscany
> Issue Type: Bug
> Components: Java SDO Implementation
> Affects Versions: Java-SDO-Mx
> Reporter: Fuhwei Lwo
> Fix For: Java-SDO-M3
>
> Attachments: org.apache.tuscany.sdo.test.SimpleDynamicTestCase.txt, patch-1085.1, simple2.xsd, simple2.xsd, SimpleDynamicTestCase.java, tuscany-1085.patch2
>
>
> Currently XSDHelper.define(InputStream inputStream, String schemaLocation) uses the second parameter to locate the importing XSD specified by the schemaLocation attribute. If the schemaLocation is incorrect, its whole namespace cannot be resolved.
> The SDO runtime should be able to look up the registered namespace and type even the xsd:import failed. Also, the users should be able to register their SDO types with their XSD referencing the sdoModel.xsd but without providing sdoModel.xsd in their applications because sdoModel.xsd is the SDO core model.
> I will attach a test case later.
--
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
[jira] Updated: (TUSCANY-1085) schemaLocation attribute in the
should be only a hint
Posted by "Fuhwei Lwo (JIRA)" <tu...@ws.apache.org>.
[ https://issues.apache.org/jira/browse/TUSCANY-1085?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Fuhwei Lwo updated TUSCANY-1085:
--------------------------------
Attachment: org.apache.tuscany.sdo.test.SimpleDynamicTestCase.txt
SimpleDynamicTestCase.java
simple2.xsd
Oops, I specified the wrong affect version.
> schemaLocation attribute in the <xsd:import> should be only a hint
> ------------------------------------------------------------------
>
> Key: TUSCANY-1085
> URL: https://issues.apache.org/jira/browse/TUSCANY-1085
> Project: Tuscany
> Issue Type: Bug
> Components: Java SDO Implementation
> Affects Versions: Cpp-M3
> Reporter: Fuhwei Lwo
> Fix For: Java-SDO-Mx
>
> Attachments: org.apache.tuscany.sdo.test.SimpleDynamicTestCase.txt, simple2.xsd, SimpleDynamicTestCase.java
>
>
> Currently XSDHelper.define(InputStream inputStream, String schemaLocation) uses the second parameter to locate the importing XSD specified by the schemaLocation attribute. If the schemaLocation is incorrect, its whole namespace cannot be resolved.
> The SDO runtime should be able to look up the registered namespace and type even the xsd:import failed. Also, the users should be able to register their SDO types with their XSD referencing the sdoModel.xsd but without providing sdoModel.xsd in their applications because sdoModel.xsd is the SDO core model.
> I will attach a test case later.
--
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
[jira] Resolved: (TUSCANY-1085) schemaLocation attribute in the
should be only a hint
Posted by "Kelvin Goodson (JIRA)" <tu...@ws.apache.org>.
[ https://issues.apache.org/jira/browse/TUSCANY-1085?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Kelvin Goodson resolved TUSCANY-1085.
-------------------------------------
Resolution: Fixed
> schemaLocation attribute in the <xsd:import> should be only a hint
> ------------------------------------------------------------------
>
> Key: TUSCANY-1085
> URL: https://issues.apache.org/jira/browse/TUSCANY-1085
> Project: Tuscany
> Issue Type: Bug
> Components: Java SDO Implementation
> Affects Versions: Java-SDO-Mx
> Reporter: Fuhwei Lwo
> Fix For: Java-SDO-Mx
>
> Attachments: org.apache.tuscany.sdo.test.SimpleDynamicTestCase.txt, patch-1085.1, simple2.xsd, simple2.xsd, SimpleDynamicTestCase.java, tuscany-1085.patch2
>
>
> Currently XSDHelper.define(InputStream inputStream, String schemaLocation) uses the second parameter to locate the importing XSD specified by the schemaLocation attribute. If the schemaLocation is incorrect, its whole namespace cannot be resolved.
> The SDO runtime should be able to look up the registered namespace and type even the xsd:import failed. Also, the users should be able to register their SDO types with their XSD referencing the sdoModel.xsd but without providing sdoModel.xsd in their applications because sdoModel.xsd is the SDO core model.
> I will attach a test case later.
--
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
[jira] Commented: (TUSCANY-1085) schemaLocation attribute in the
should be only a hint
Posted by "Fuhwei Lwo (JIRA)" <tu...@ws.apache.org>.
[ https://issues.apache.org/jira/browse/TUSCANY-1085?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12471700 ]
Fuhwei Lwo commented on TUSCANY-1085:
-------------------------------------
Hi Kelvin,
I know my fix is a little kludge. It's probably because I am either not familiar with EMF enough or it's an EMF design limitation.
Based on my reading into the code, my understanding is that XSDEcoreBuilder is designed to build its in-memory model based on XSD but not the combination of XSD and the registered types in the memory. If you looked at the existing methods computeEClass and computeEClassifier in the SDOXSDEcoreBuilder, you would find someone has already tried to expose the registered built-in SDO model types, e.g. sdoModel.xsd, from the memory. What I did was to extend the code to expose all the registered types besides the SDO core model types.
Unfortunately, exposing the types in the computeEClass and computeEClassifier is not enough because the createFeature() will create the feature only based on the information from the XSD. I have tried to override the getEffectiveTypeDefinition() to return the correct type for the feature but it seems tied to the XSD information. That's why I override the createFeature() to set the correct containment value for the complex type feature if the type returned by getEffectiveTypeDefinition() is incorrect which is currently the only problem I am seeing.
I agree the fix should eventually come from EMF but am not sure about the scope and time frame. That's why I am taking the first shot to get this going. Thanks.
> schemaLocation attribute in the <xsd:import> should be only a hint
> ------------------------------------------------------------------
>
> Key: TUSCANY-1085
> URL: https://issues.apache.org/jira/browse/TUSCANY-1085
> Project: Tuscany
> Issue Type: Bug
> Components: Java SDO Implementation
> Affects Versions: Java-SDO-Mx
> Reporter: Fuhwei Lwo
> Fix For: Java-SDO-Mx
>
> Attachments: org.apache.tuscany.sdo.test.SimpleDynamicTestCase.txt, patch-1085.1, simple2.xsd, simple2.xsd, SimpleDynamicTestCase.java
>
>
> Currently XSDHelper.define(InputStream inputStream, String schemaLocation) uses the second parameter to locate the importing XSD specified by the schemaLocation attribute. If the schemaLocation is incorrect, its whole namespace cannot be resolved.
> The SDO runtime should be able to look up the registered namespace and type even the xsd:import failed. Also, the users should be able to register their SDO types with their XSD referencing the sdoModel.xsd but without providing sdoModel.xsd in their applications because sdoModel.xsd is the SDO core model.
> I will attach a test case later.
--
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