[jira] Commented: (TUSCANY-1085) schemaLocation attribute in the should be only a hint

["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