[12:04] Ron: I - Intro 
a. Roll Call 
b. Assignment/Confirmation of Scribe 
c. Approval of last weeks minutes: http://www.oasis-open.org/apps/org/workgroup/sdo/download.php/39902/SDO%20TC%20Meeting%20minutes%20-%20October%2019%2C%202010.txt 

d. Agenda Bashing 


No new AIs 


No New Issues. 

IV - ISSUE-186: Missing normative statements in section 4.13.2 
JIRA: http://www.osoa.org/jira/browse/SDO-186 
Proposal here: http://www.oasis-open.org/apps/org/workgroup/sdo/email/archives/201010/msg00029.html 

V - Review Comments to Core Spec Chapters 5-8 
Baseline here: http://www.oasis-open.org/apps/org/workgroup/sdo/email/archives/201010/msg00030.html 
Note from Bryan to section 5.2 here: http://www.oasis-open.org/apps/org/workgroup/sdo/email/archives/201010/msg00028.html 
Note from Ron to section 5.3 will be posted before the start of the meeting
[12:07] Bryan Aupperle: Topic: Approval of Minutes
[12:07] Bryan Aupperle: Resolution: Minutes approved w/o
[12:08] Bryan Aupperle: Topic: Issue 186
[12:16] Bryan Aupperle: Bryan present the proposal
[12:16] Bryan Aupperle: Discussion about the last statement in the proposal
[12:21] Bryan Aupperle: Agreement to strike last statement of proposal.
[12:25] Bryan Aupperle: When an SDO implementation generates an XSD the it MUST adhere to the rules in 8:  Generation of XSD from SDO Type and Property. [COR04130201]
[12:25] Bryan Aupperle: Updated proposal:
[12:26] Bryan Aupperle: 4.13.2        Using XSDHelper for Types Without an XSD Definition 

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 the it MUST adhere to the rules in 8:  Generation of XSD from SDO Type and Property. [COR04130201]
[12:26] Bryan Aupperle: If an XML Schema was originally used to define the Types, the original XSD SHOULD be used instead of generating a new XSD. [COR04130202] An XSD can contain more information than a Type definition so a generated XSD is not guaranteed to be compatible the original XSD and might validate different documents.
[12:38] Bryan Aupperle: Discussion to continue on e-mail with Blaise to produce next draft of a proposal.
[12:41] Bryan Aupperle: Topic: Rewording of 5.2
[12:42] Bryan Aupperle: Proposed rewording in e-mail is accepted as an editorial change.
[12:48] Bryan Aupperle: Topic: Section 6.1
[12:48] Bryan Aupperle: Strike: None of the types have any Properties unless noted. All values are false unless noted.
[12:50] Bryan Aupperle: Strike (in second paragraph): When code is generated with accessors of type T, the behavior is identical to the get<T>(property) and set<T>(property) methods.
[12:54] Bryan Aupperle: Topic: Section 7.1
[12:54] Bryan Aupperle: Strike: 10.We do not allow design changes that complicate the simple cases to solve more advanced cases.
[12:55] Bryan Aupperle: Topic: Section 7.2
[12:58] Bryan Aupperle: Remove this section as out of scope
[13:04] Bryan Aupperle: Related change in 7.1, strike: 12.Normally, SDO names are the same as the XSD names. To change the SDO name user can annotate an XSD with sdox:name annotations. In some cases, for example in the case of duplicate component names or anonymous XSD types, the original XSD names cannot be used in SDO. In such cases, an SDO-aware code generator tool will generate new names and virtually add sdox:name annotations to the original XSD. Then, the tool will use the Annotated Schema to generate SDO. Such tool would be able to serialize the Annotated Schema at user request. Note: an SDO implemention MUST NOT generate names for anonymous types that hide a globally defined type with the same name. [COR07010001]
[13:07] Bryan Aupperle: Meeting Attendees
Name Company Status
Bryan Aupperle IBM Group Member
Shawn Moe IBM Group Member
Blaise Doughan Oracle Corporation Group Member
Ron Barack SAP AG* Group Member