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] Conference Call Minutes 06/DEC/01


Attendees:
Bill Burcham - YES (jointed at x:15)
Dave Carlson
Mark Crawford
Matt Gertner (chair) - YES
Arofan Gregory
Eduardo Gutentag - YES
Eve Maler - YES (joined at x:08)
Gunther Stuhec

Also attending as an observer was Dale McKay.

(1)

Matt raises the issue of the dependencies of context rules on work in the
NDR SC:
	- Schema language
	- Derivation features
	- Additive vs. substractive methodology
	
Eduardo points out that the decision not to use any derivation mechanism
would remove a lot of these dependencies. Eve supports the assertion that we
should be defining a transformation that is not dependent on derivation. In
addition, there are examples (like extending code lists) that require ad hoc
methods anyway.

Matt mentions three possibilities:
1) No derivation, just a transformation.
2) Use of XSD because of extension and restriction features.
3) Coordinate with RELAX NG to create a type derivation mechanism that
better integrates business requirements.

Eduardo points out that the ebTWG is using RELAX NG for their schema
modeling. Dale maintains that we have no chance of imposing RELAX NG, so we
should accept XSD and work around the limitations. Eduardo says that ebXML
CC context metholodgy has no dependencies on XSD. Matt points out that the
decision of using restriction is important nonetheless. Eduardo: Yes, but
codelist extension is required also and this is not supported in XSD.

Discussion of separating the issues of extension methodology from the schema
issues (especially derivation) and pursuing in separate threads. General
agreement.

Discussion of whether to move the extension position paper to the CM SC.
Depends on whether many members of the NDR SC who are not in the CM SC are
interested in these issues.

General agreement that XSD will be the standard language for core component
and BIE modeling. Eduardo: We should wait to see if compelling reasons arise
for preferring RELAX NG over XSD. Eve points out that it would be very
useful to have RELAX NG versions of schemas since there is a formal process
for determining unions and intersections of schemas. Also, further types of
extension not supported by XSD can be cleanly layered on top of RELAX NG.
General agreement that for these reasons we should at least ensure that
nothing in our design precludes use of RELAX NG.

Matt asks whether we want to suggest that we take over the work of the NDR
SC on the extension positioning paper since we have more bandwidth. Eduardo
and Eve don't see a problem with it. Matt as chair will send a mail to the
NDR SC suggesting this step, and see if anyone has a problem with it.

(2)

Matt states the problem, which is that no one in the CM SC is volunteering
to develop use cases for the context extension methodology. Some informal
discussions has led him to believe that it might be better to turn to the
Core Library SC to do this. Eduardo reinforces this by pointing out that the
business types also don't like it when geeks come up with use cases that
aren't realistic in the real world.

Matt will write to Tim directly, copying Arofan, and ask to what extent they
would be able to help us with the use cases. Suggestion to copy Sue as well.

(3)

Discussion of next steps. Review of issues originally raised on list and
decisions so far:

1) Yes, the Vienna document will be the basis of our work.
2) Should we use XSD derivation? Continue to discuss but decouple from
specification of extension mechanism.
3) Assume that we will need features for both additive and subtractive
extension.
4) An adhoc XML format will be used for the specification of context rules.
5) Eve's suggestion for using text matching to handle hierarchical context
driver values met with some approval but does not solve all issues.
Discussion will be continued on the mailing list.
6) No need for assembly rules.
7) We choose good names that make sense and not bind them to XSD.
8) We should make use cases and test them against the Vienna doc to find any
"broken" features.

Next steps:
- Continue to discuss open issues listed above (derivation and hierarchical
context drivers).
- Take over work on Arofan's positioning paper if the NDR SC agrees.
- Solicit use cases from the Core Library SC.


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


Powered by eList eXpress LLC