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
- From: Bryan Aupperle <aupperle@us.ibm.com>
- To: "sdo@lists.oasis-open.org" <sdo@lists.oasis-open.org>
- Date: Fri, 12 Nov 2010 08:30:15 -0500
"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:
- The user already has access to the original schema.
- Since the original schema already exists it is a waste
of memory to store the XML schema only to return it later, since it may
never be asked for.
- Our (Oracle) users use a lot of imported/included schemas
which would make it difficult to return the original schemas.
- The XSDHelper generates schemas off of a list of types,
what subset of types derived from the original define need to be passed
to the generate to trigger the original schema to be returned.
- Since the generated schema may be incompatible with the
original schema (as per the spec), the generated schema gives users realistic
expectations of what there XML document will look like.
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]