[ubl-cmsc] Conference Call Minutes 19-DEC-01

[Matthew Gertner <matthew.gertner@schemantix.com>]

UBL NDR SC and CM SC Joint Conference Call Minutes
December 19, 2001

Role Call:

Bill Burcham -- YES
Doug Bunting -- YES
Dave Carlson
Mavis Cournane
Mark Crawford -- YES (x:36)
John Dumay -- YES
Matt Gertner -- YES
Jack Gager
Arofan Gregory -- YES
Eduardo Gutentag -- YES (x:25)
Eve Maler -- YES
Dale McKay -- YES
Sue Probert -- YES
Gunter Stuhec
Mike Rawlins
Ron Schuldt -- YES

Agenda: Come to conclusions on any and all aspects relating to extensions.

Minutes:

Arofan says that Gunter has some further issues regarding tag naming that he
wants to raise in the next call, before this is finalized. (He is on
vacation and couldn't make the call.)

Issue raised as to whether the extension paper should be officially
transferred from the NDR SC to the CM SC. Decision to table this until the
end of the call, to see if sufficient consensus has been reached to take
this step.

Arofan says that we should focus on specific issues with the goal of making
sure that enough consensus exists for the CM SC to move forward on the
extension issue. Arofan describes the main issue as relating to the
potential decision to model components and documents as XSD files with
metadata (in the appInfo tags) that describe context information. The
context language should be expressed in XML and should transform the core
schemas into business schemas. The big issue is subtractive refinement,
because we know that no verifiably complete implementation of refinement
exists today. There is also no means to distinguish between optional
elements that can be removed and those that cannot.

Matt restates this as determining to what extent we want to bind the
extension mechanism to a specific schema language considering that we know
that no schema language supports everything that we will need. It would
therefore make sense to design the extension methodology using only features
of the schema language relating to document structure (which tend to be very
similar across all schema languages), and use schema annotations to describe
all other aspects (context, derivation relationships, etc.). The decision of
whether to use appInfo for the annotations should be discussed.

Eve points out that the decision to use XSD for the modeling language has
already been made. And this is orthogonal to the decision that Matt is now
proposing. Arofan says that the Core Library SC is assuming use of XSD for
modeling. General consensus that we have settled on XSD.

Dale makes a supporting statement for Matt's proposal by pointing out that
in his organization, programmers have tended to take this approach for
practical reasons. Matt adds that sticking to the structural features of XSD
will also eliminate a lot of the objections that people have to XSD.

Arofan raises the issue of whether we should at least express the features
for representing type relationships, since we feel that these relationships
will be important, so we might as well use the features that are there. Matt
objects because this will cause all the issues about, e.g. use of
refinement, to rear their head again.

Eve restates this with the following disjunct options:
(1) Use none of the features of XSD.
(2) Use the features of XSD when they are there, but use an ad hoc approach
for things that are not supported by XSD.

Matt insists that (2) would make us face the issue of refinement (and
others).

Arofan says that in his position paper, he is advocating a mechanism that
lets you add things, and then refine things down, rather than settling for
one or the other. Using a two-step process is not as messy, but it does
dictate to people how they have to do processing. Eve says that this is the
only way that makes sense. Arofan says that various industry groups are
already considering this kind of approach. Eve thinks out loud: this would
require that the extension mechanism let you remove stuff ONLY if it has
already been added in the previous step (i.e. it's not built into the
standard component).

Arofan says that if we can agree on this, this is the key thing. Eve points
out that the process currently proposed by v1.04 (the Vienna document) is
not two-step. But this isn't really a problem. We all agree that this is not
a finished work.

Doug has just one question: in what cases does refinement come into play?
Since we are talking about groups of core components that can be removed as
needed, so where would refinement come into play for the individual
components? Arofan and Matt point out that the components (and BIEs) are
recursive, so they can contain component parts as well that might have to be
refined out in certain contexts. Doug continues: he can see why removing
components from a BIE (if you've added too much before), but that the core
component should be truly core, so there wouldn't be need to remove
anything. Arofan says that the CL SC is not defining minimal components,
they are designing 80/20 components, so they contain a lot more than most
people will need (implying that refinement will be needed).

Doug argues that this might hamper interoperability, since some parties
would not be using components that are needed in 80% of cases. Matt says
that this might be a misrepresentation of the 80/20 rule, which really
indicates that the optional elements might be needed, but the fact that they
are really required will be determined by context. Arofan points out that
there needs to be distinction between optional (and can be removed) and
optional (and needs to be kept as optional).

Ron gives the example where a supplier enterprise identifier might be
needed. Some parties might just call this "enterprise identifier", while
others might want to distinguish between "supplier enterprise identifier"
and "manufacturer enterprise identifier". Arofan says, in essence, that this
is an issue addressed by UBL but not necessarily by the context extension
methodology. What is really relevant is whether, contextually speaking, a
buyer id or whatever is required by a pair of trading partners. This can be
enforced by having controlled vocabularies. In essence the problem raised by
Ron will be solved by intelligent schema design inside the CL SC.

Matt summarizes issues:
(1) Should we depend on just the structural features of XSD and worry about
what type derivation features we use later?
(2) Do we accept Arofan's two-step process for extension (first extending
and then refining)?
(3) Do we need special optional elements that are either: (a) removable, (b)
not removable and (maybe) (c) not allowed to be made required.

Dale suggests that we just accept (2) for now, and then see if any issues
that are raised as we work the use cases. All agree.

Matt restates the problem of (1) (see above in this minutes document since
it's already outlined). Arofan objects to the idea that the importance of
type derivation information in the schema is proven to the extent that
Commerce One has used it for some time to build software architectures. Doug
raises some objections because processing apps might choke on derived types
that are somehow not compatible with the base type. Arofan points out that
optional fields really mean optional at design time, so by run-time we
should know which information to expect.

Eduardo says that the more Arofan argues his point, the more he feels that
it would be very hard to take care of derivation relationships in real
running code. Matt argues that we really don't have to worry about
expression in schema about this point, that we should forge ahead with
designing the context extension metholodgy and worry about this later.
Arofan asks if anyone objects to this. No one speaks up so we are moving
ahead with this assumption.

Next Steps:

Decision to hold next NDR SC call on January 2nd. Topics will be:
(1) Tag structure (1st hour)
(2) Modularity, naming and versioning

A separate CM SC call will be planned.

Meeting will be held at "normal" time (11am-1pm EST). Eve will send an
agenda.

Happy Holidays!

----------------------------------------------------------------
S C H E M A N T I X        *   TOMORROW'S SOLUTIONS TODAY
Chief Executive Officer    *   www.schemantix.com
----------------------------------------------------------------