XSDHelper#define 2-1. loads XSD as well as imported/included ones (as XSD model) 2-2. converts all XSDs to SDO Types (as SDO model)
sdoModel.xsd is converted/generated to SDO Types already. It's possible not to repeat 2-1 and 2-2 when sdoModel.xsd is imported by user XSD, therefore sdoModel.xsd isn't mandatory for SDO impl. sdoModel.xsd may be useful to non-SDO tools such as third party XSD/XML validator. Having sdoModel.xsd with SDO API may have satisfied that. On 1/30/07, Fuhwei Lwo <[EMAIL PROTECTED]> wrote:
Scenario - SDO users have XSDs that would reference types defined in sdoModel.xsd. It's inconvenient for the users to include the sdoModel.xsdin their apps. They should be able to register their types in XSD with SDO runtime since sdoModel.xsd is SDO's built-in model. To satisfy the scenario above, the SDO impl project needs to access the sdoModel.xsd currently in the SDO API project. I am interested in knowing the best approach to accomplish this in both OSGi and non-OSGi environment for SDO. I personally would like to have a copy of sdoModel.xsd in the SDO impl project for performance and convenience purposes. Any comments?
-- Yang ZHONG
