On 15/12/06, Frank Budinsky <[EMAIL PROTECTED]> wrote:
In the SDO collaboration workgroup meeting yesterday, it was agreed that improved XSD fidelity is an important issue that needs to be addressed to make SDO successful in the web services use case. A JIRA issue for this, attached below, has been opened in the SDO collaboration JIRA database, and will be one of the high priority items to be discussed. Although the issue is targeted for SDO 3, the collaboration has also discussed the possibility of producing an earlier 2.2 release which might include a subset of the 3.0 resolutions, if some (like this issue may be) are considered too important to wait for SDO 3. What we need help with is formulation and clarification of the issues. What XML constructs are awkward, or even impossible, to work with using SDO? Please check the list of known items below and let me know if you have additional ones or comments on the existing issues. Any specific preferences about how any of these issues are addressed would also be very welcome. Thanks, Frank. SDO-197: Improved SDO/XSD Fidelity Using SDO to represent web service data is an important SDO use case. Since XSD is the type system, SDO must provide good fidelity with XSD in order to be successful in this application. SDO already provides good support for XSD, but by simplifying the user model SDO has made a few common features of XSD difficult, if not impossible, to work with. The objective of this feature is to ensure that SDO provides good fidelity/support for all XSD features found in common industrial schemas, and to also ensure that SDO also provides a fallback mechanism for handling the remaining XSD corner cases. This feature will be used to create and discuss the list of issues that need to be considered, after which separate issues will be opened to address the individual fixes/changes that we ultimately decide need to be made. The following lists the issues known so far. Please add any new issues that you know of, or add comments/clarifications for the existing issues. the "." character in Type and Property names must be completely supported (issue SDO-187 to address this) support duplicate property names allowed by separate XSD namespaces for attributes and elements - handing of "@" in SDO XPath (issue SDO-192 opened for this)
This looks like what I have run into in the C++ implementation (discussion on another thread) where my conclusion was property names need to be QNames. XSD facet constraints and validation support
xsd:key/xsd:keyref handling/support improved handling of xsd:restriction derivation? improved handling of xsd:choice? consistent fallback strategy (e.g., open/sequenced dynamic DataObject) for handling XSD corner cases --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
What is your timescale for this work. It's something I've worked a lot on in the C++ area.. but I'm of fon leave for 2 weeks now! Cheers, -- Pete
