[
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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
