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 10-APR-02 Call


Attendees:
Bill Burcham		YES (left at X:26)
Dave Carlson 
Mark Crawford 		YES
Fabrice Desr? 
Matt Gertner		YES
Arofan Gregory 		YES
Phil Griffin 
Eduardo Gutentag 	YES
Eve Maler 		YES
Dale McKay 
Aidan Shackleton 
Gunther Stuhec 
Chandra Tamirisa 
Paul Thorpe 		YES

Marion Royal joined as an observer at X:13.

Quorum reached at X:09

---

(1) Review of use case status

Use cases from January face-to-face are compiled and on the portal. Mainly
the use cases come from the LC SC. Comments have been logged from the
Barcelona face-to-face and a subsequent call with Matt, Bill, Eduardo and
Paul. The comments will be added to the portal before the next call.

Arofan says that they are not really use cases because they make too many
assumptions about the actual document formats. Matt says that it is probably
not realistic to compile use cases that are divorced from all assumptions,
but it is true that a lot of the use cases are not that useful or overlap
with others. Matt suggests that comments to the LC SC on specific schemas
could be caught by Arofan, as the liaison, could catch these cases and
transmit them to the CM SC.

Eve suggests that we write test cases to validate the use cases. Matt
extends this possibly to a preliminary spec based on our expert knowledge
and current use cases. Arofan proposes using xCBL to assist in test cases
while we wait for the LC SC to produce additional document formats beyond
the current Order (which could already be used for testing) Eduardo sees a
problem since the rules may depend on the final decision of how to structure
the derivation relationships (DWP, TAAT, Paella, etc.).

Arofan suggests that Eduardo's point might be very useful in validating the
advantages of Paella vs. TAAT. Eduardo responds that we will have to
simulate an engine every time we do a case. A: This is exactly what we are
trying to evaluate. Eve: We could group cases into categories and associate
with types of rules like "add an element". Matt: Excellent idea, although
the coverage is not that broad. New cases can be folded in and are unlikely
to invalidate the entire approach.

A: We have gathered use cases that represent how documents are actually
modified according to context. We need to evaluate more complex cases such
as applying several rules to a single document in order to tackle issues
like rule ordering, etc. M: Let's define a couple of complex test cases and
assign to-dos for two people to run these cases using TAAT and Paella so we
can compare.

Inputs: schema, context values for several drivers and a set of rules taken
from the use cases
Outputs: modified schema, formal rules

A: Let's clean up the use cases, identify patterns and take representative
cases, rather than applying the same kind of rules over and over.

Action: Clean up use cases and identify patterns -- Matt
Action: Create test cases based on different combinations of context drivers
-- Arofan
Action: Work through test cases using TAAT -- Eduardo
Action: Work through test cases using Paella -- Bill

Action items may be revised and responsibilities reallocated once
preliminary work is done.

(2) DWP/TAAT/Paella issues

General agreement that DWP has been subsumed by Paella. Basic agreement that
the concepts of Paella are understood, although some refinement may be
necessary. Discussion postponed until Bill can participate.

Eve: I am concerned that until we work through a TAAT example, I don't have
high confidence that it will have more success than other methods that the
propagation of changes up the document hierachy can be avoided. M: We agreed
on the March 29th call that to change the type of a parent is absolutely
right and correct when a child type is changed. E: We made a choice to go
with local elements, so only types, not elements are reusable. This means
that all parent types must be totally redeclared and cannot be derived from
the original parent type.

A: TAAT solves this problem because the new type can copy the content of the
old type, but there is no real derivation relationship there. The attraction
is that Paella may be too complex for developers to understand, hampering
adoption of UBL. E: We should get more input from outside developers before
we assume this.

M: Maybe we can use TAAT in order to create the context rule methodology,
use Paella as a "workaround" in the short , middle and possibly long term in
order to use XSD derivation, and then lobby for a derivation mechanism that
meets our requirements better in the longest term. Doesn't refinement do
this? Needs more investigation.

Action: Create simple TAAT case that will guide further discussion --
Eduardo
Action: Write article outlining problems with XSD derivation in relation to
UBL, investigate whether refinement covers this case -- Matt

(3) Other issues

Postponed until next call.

(4) Planning for authoring spec

Will be addressed after next action items are completed.

---

Call ended at Y:06



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


Powered by eList eXpress LLC