Difference between revisions of "ITS WGM Minutes 2011 Jan"
Astechishin (talk | contribs) |
Astechishin (talk | contribs) |
||
| Line 194: | Line 194: | ||
===Q3=== | ===Q3=== | ||
| − | + | ''Did not meet'' | |
| − | |||
| − | |||
===Q4=== | ===Q4=== | ||
| − | + | ''Did not meet'' | |
| − | |||
| − | |||
==Thursday, January 13== | ==Thursday, January 13== | ||
Revision as of 05:13, 1 February 2011
ITS - Sydney Australia, WGM January 2011
Co-Chairs
Paul Knapp (PK) Dale Nelson (DN) Andy Stechishin (AS)
Monday, January 10
Q1
Chair: PK Scribe: AS
Discussion of planned activities for the week
Brief discussion of Green CDA and its relationship to ITS WG
Discussion on hData preparations for ArB session.
Agenda updates posted to Wiki and a message sent to the list server
Q2
Chair: PK Scribe: AS
Q3
Chair: PK Scribe: AS
Q4
Chair: PK Scribe: AS
Tuesday, January 11
Q1
Chair: PK Scribe: AS
Q2
Joint with Structured Docs
Q3
Chair: PK Scribe: AS
Q4
Did not meet
Wednesday, January 12
Q1
Chair: PK Scribe: AS
Q2
Chair: PK Scribe: AS, DN
We (ITS) SPL does not want to adapt changes in DT R2 which would mean a lot of changes. It was agreed they would use R1.1, by trading partner agreement. We have a Norm spec that depends on an Inform spec. It is desired to make it Normative. Grahame objects, and wishes to call it DT 2B.
Is the wires format the same in R2 DT as
At abstract, they are implementing DT R2
Datatypes Version Abstract Basis Status Notes
1.0 1.0 Normative
1.1
2.0
Informative
Normative? 2B?
2.0 2.0 Normative
XMLITS
Version
Based on
Status
1.0
DT 1.0
Normative
1.1
DT 1.0
Normative
2.0
DT 2.0
Normative
Tooling
Version
ITS
DT
1.0
1.0
1.0
1.1
1.1
1.1
2.0
2.0
2.0
Which ballot are we talking about John Koisch: redo it using ISO datatypes in a correct way. GG: But that breaks their non-backwards compatibility chain. DN: Has HL7 guaranteed BW compatibility? GG: V2 yes, V3 semantic only. PK: We need to think about what the organization should be doing. Perhaps a straw vote. 1.1->Normative 0 1.1->2Minus 3
Should Normative docs stand on Informative docs: No.
UUID: Issue is in the schema, not the spec. If we were to change the schemas, this is a tech correction. PK: UUID Abs 1 & 2 said UC. If it says case insentive, then we my just have a case in the later schema is incorrect. JK: It is transform away. Can SPL provide the transform? PK: require everyone to do local fixes. PK: We have been consistently wrong, and we finally got it right. Do we force everyone to clean it up or do we fix in a future version? GG: All say comparisons are case insensitive. Version Abstract ITS Schema 1.0 Upper Mixed Mixed 1.1
Mixed Mixed 2.0 Upper Upper Upper (annotate)
GG: Should be TC that 1.0 and 2.0 Abstract are wrong
Motion: The Abstract DT 1.0 & 2.0 descriptions of UUID being upper case be changed to mixed case. (GB, AS) 8/0/1
Action: That GG amend the Abstract Data types, and all associated artifacts.
Motion: (GG/AS) 9-0-0 (1) Do not want to make DT 1.1 backwards compatibility track normative (2) We will if asked by TSC, but want to know how we will avoid maintaining two streams going forward. (3) If it goes normative we will give it an R2 label,
Q3
Did not meet
Q4
Did not meet
Thursday, January 13
Q1
Did not meet
Q2
Chair: PK Scribe: AS
Q3
Did not meet
Q4
Chair: PK Scribe: AS
Attendees
| Name | Initials | Monday | Tuesday | Wednesday | Thursday | |||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Q1 | Q2 | Q3 | Q4 | Q1 | Q2 | Q3 | Q4 | Q1 | Q2 | Q3 | Q4 | Q1 | Q2 | Q3 | Q4 | |||
| Andy Stechishin | AS | andy.stechishin@gmail.com | ||||||||||||||||
