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

 


Help: OASIS Mailing Lists Help | MarkMail Help

ubl-cmsc message

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


Subject: [ubl-cmsc] Minutes from 1 May 2002 CM SC Call


Minutes from 1 May 2002 CM SC Call

Attendees:
Bill Burcham  	YES
Dave Carlson 
Mark Crawford   	YES
Fabrice Desre
Matt Gertner  	YES
Arofan Gregory   	YES
Phil Griffin   	YES
Eduardo Gutentag
Eve Maler   	YES
Dale McKay 
Aidan Shackleton 
Gunther Stuhec 
Chandra Tamirisa 
Paul Thorpe

Sue Probert, Lisa Seaburg as observers

---

Agenda: TAAT, Paella, Matt's idea, decision-making process

---

Outline of problem, why we might want/not want a derivation relationship
between core schemas 
and those created using the context extension methodology. Some discussion
of the drawbacks of 
TAAT, the fact that it is still not clear exactly what it is. We know it
isn't XSD derivation, 
but we don't want it *is*.

Discussion of whether using something like the Schema Adjunct Framework (as
in Matt's proposal) is actually feasible since it would require new
capabilities for existing processors. Comments of the tie-in of Schematron
to the issue (the fact that Schematron permits much more powerful
constraints and is widely used). Speculation that a normal Schematron file
could be used instead of an adjunct file (which has much less mindshare).

Rebuttal by Bill of the assertion that restriction is not really derivation.
Extension of a complex type is the same thing as restriction of a simple
type. This is disputed, since extension does not appear to be a
specialization.

Arofan suggests a way to get to the bottom of this: what we want to capture
through the CM is a way so that all of the created schemas are compatible
with processors designed for the old schemas. We should establish whether
order is important. If this is not so (i.e. order can remain fixed), then
XSD derivation should be valid. A solution would be to use extension for
extending schemas, and use Schemantron for all restriction. Old processors
will then accept the restricted schemas but accept too much, and they simply
have to support Schematron as well in order to take into account the new
constraints.

Action: Matt will coordinate with Eduardo to extend Bill's paper to
integrate Eduardo's refinement of what TAAT is and the Schemantron scenario.
Very important to take into account the proposed requirements from Bill
using evaluation matrix.   

Action: Tie together the low-level requirements from his paper with the
business-level use cases. To be discussed on next call. Everyone should
think about this in the interim. 

Action: Matt will place Bill's paper on the CM portal.


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


Powered by eList eXpress LLC