OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

sdo message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: Re: [sdo] Proposal: Section 4.13.2 - Generating XSDs


"should" is a RFC 2119 keyword, so if we keep the "should" in the second paragraph is needs to be in all caps and the statement tagged.  Same issue with "may" later in the paragraph (only in this case, I do not think that is the intent) The last sentence of the first paragraph still seems like a compliance point.

So, how about this (a combination of the proposals and the discussion on the last call):

4.13.2 Generating XSDs

The XSDHelper can generate a new XSD for Types that do not already have an XSD definition. This is useful when the source of the Types come from services in another domain, such as relational databases, programming languages and UML.
When an SDO implementation generates an XSD it MUST adhere to the rules in 8:  Generation of XSD from SDO Type and Property. [COR04130201]

If an XML Schema was originally used to define the Types, that original XSD
SHOULD be used instead of generating a new XSD. [COR04130202] If a new XML Schema is generated when one already exists, the generated schema might be more lax than the original schema.  In certain circumstances the XML schemas might not be compatible.

Bryan Aupperle, Ph.D.
STSM, WebSphere Enterprise Platform Software Solution Architect
WW Center of Excellence for Enterprise Systems & Banking Center of Excellence Application Integration Architect

Research Triangle Park,  NC
+1 919-254-7508 (T/L 444-7508)
Internet Address: aupperle@us.ibm.com



From: Blaise Doughan <blaise.doughan@oracle.com>
To: "sdo@lists.oasis-open.org" <sdo@lists.oasis-open.org>
Date: 11/11/2010 04:41 PM
Subject: [sdo] Proposal:  Section 4.13.2 - Generating XSDs





Hello All,

For section 4.13.2 we (Oracle) feel that XSDHelper should always return an XML schema generated off of the SDO metadata (as opposed to returning the original schema).  Our rationale is as follows:
As promised in the last SDO call, here is my proposed wording on section 4.13.2.  Since the spec already stated that the original XSD should be returned, I don't feel this needs to be changed.  However the compliance point must not require this behaviour (although it may encourage it).  As concessions have been made in other areas to give implementations freedom to do what is best for their customers, I propose we do the same here.

Current Wording


4.13.2 Generating XSDs


The XSDHelper can generate a new XSD for Types that do not already have an XSD definition. This is useful when the source of the Types come from services in another domain, such as relational databases, programming languages and UML. The generated XSD format is described later in 8:  Generation of XSD from SDO Type and Property.

If an XML Schema was originally used to define the Types, that original XSD should be used instead of generating a new XSD.
If a new XML Schema is generated when one already exists, the generated schema and the original schema will not be compatible and will validate different documents. The XMLHelper will follow the original XSD if one exists, otherwise it will follow a generated XSD.

---

Proposed Wording


4.13.2 Generating XSDs


The XSDHelper can generate a new XSD for Types that do not already have an XSD definition. This is useful when the source of the Types come from services in another domain, such as relational databases, programming languages and UML. The generated XSD format is described later in 8:  Generation of XSD from SDO Type and Property.

If an XML Schema was originally used to define the Types, that original XSD should be used instead of generating a new XSD.
If a new XML Schema is generated when one already exists, the generated schema may be more lax than the original schema.  In certain circumstances the XML schemas may not be compatible.

-Blaise




[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]