| Subject: | [Issue 47] TCK: XSDHelperTest.testRedefinition | |
|---|---|---|
| From: | radup (rad...@dev.java.net) | |
| Date: | Aug 28, 2008 6:57:31 pm | |
| List: | net.java.dev.jsr235.issues | |
https://jsr235.dev.java.net/issues/show_bug.cgi?id=47
User radup changed the following:
What |Old value |New value ================================================================================ Status|RESOLVED |REOPENED
-------------------------------------------------------------------------------- Resolution|FIXED |
--------------------------------------------------------------------------------
------- Additional comments from rad...@dev.java.net Fri Aug 29 01:57:54 +0000
2008 -------
Reopened by Frank and discussed on the mailing list and the Aug-21 and Aug-28
conference calls.
New proposal: Add the following clarification to section "3.13 XSDHelper":
When defining SDO medatada from a particular Schema, it can happen that some of the components defined by that Schema (directly or via XSD imports or includes) map to SDO Types and Properties with the same name and namespace URI as existing Types and/or Properties. If an implementation can determine that the XSD components that the existing Types/Properties have been mapped from and the new components have the same identity, then the existing SDO Types/Properties are used instead of defining new ones.
Add the following to the XSDHelper.define JavaDoc (see also issue 62):
@return the defined types. Not all of the XML Schema types cause an SDO type to be defined (for example in case of duplicates), the returned list only includes the newly defined types.
Change the TypeHelper.define JavaDoc from:
* For every item in the input List, the output list will contain either the Type newly defined * or a pre-existing Type in case a Type with the given name already exists.
to:
* The output list will contain, for every item in the input list, either the Type newly * defined or a pre-existing Type in case a Type with the given name already exists, followed * by any other types defined as a result of this call.
The reason I worded the TypeHelper.define JavaDoc in this way is to keep the one-to-one correspondence between items in the input List and items in the output List.





