RE: The role of context in the re-usability of Core Components an dBusiness Processes - OR Say What???

["Gregory, Arofan" <arofan.gregory@commerceone.com>]

Dear Robert Miller:

None of the work the context group has done *requires* automatic assembly,
although I strongly dis-agree with your intuition about such a process not
producing a useful schema reflecting industry concerns. It is simply that by
capturing contect information, and making it available in a form that is
both processable and human-readable (the rules are in XML formats, as you
have seen), no meta-data is lost, and none of the possible schema-creation
options are lost.

I would also suggest that - because different types of schemas are not
easily comparable in an automated way - that a schematic "map" of the
context-specific document is a useful aretefact for comparing different
schemas' semantics *before* they are bound to a particular syntax. The
usefulness of such an aretfact for a tool such as GXS' AI might be quite
substantial, in fact.

Basically, I simply want to re-assure you that the context group is not
making assumptions about how contexts will be used, but *is* trying to
enable both manual and automated approaches.

Cheers,

Arofan Gregory

-----Original Message-----
From: Miller, Robert (GXS) [mailto:Robert.Miller@gxs.ge.com]
Sent: Thursday, March 15, 2001 10:11 AM
To: Martin Bryan; Miller, Robert (GXS); William J. Kammerer; ebXML Core
Subject: RE: The role of context in the re-usability of Core Components
an d Business Processes - OR Say What???


Martin,

My comment about eliminating optional fields was a tongue-in-cheek comment
prompted by another thread in which William Kammerer was trying to explain
why the spreadsheet column for REQUIREMENT (Mandatory/Optional) was
redundent to MinMaxOccurs (0.. / 1..).  

I was not aware of any distinction made between 'assembly' rules and
'context' rules (in the spreadsheet - as you observe, such distinction is at
least conceivable.)

I happen to have utmost confidence in the ability of industry groups to
produce schemas that reflect their required 'assembly' rules.  But I have
zero confidence that an algorithmic process bombarded with assembly rules
representing a myriad of assembly contexts for a core component would
produce the schema a given industry expected and required to meet their
member needs.  Among other problems, how does one discern whether a given
rule an 'assembly rule' or a 'context' rule in the realm of a specific
industry.  There likely is interplay among the various contexts that affect
what is an 'assembly' rule and what is a 'context' rule for any of the
possible combinations of contexts (though of course not all possible context
combinations are likely to occur in real life).  My argument therefore is
that there are no 'assembly' rules, only context rules.  When an industry
association produces a schema which omits parts of a core component, in so
doing it acknowledges that some context rules could be applied at assembly
time, and in so doing, the context rules associated with the omitted
entities are gone with the omitted entities themselves. 

While I support efforts to capture context information in the metadata
associated with core components, I do not share the vision of some that this
information will then be used to automatically generate schemas.  Instead, I
expect that an industry group would follow much the same process it now
follows with an X12 or UN/CEFACT 'scheam'.  It starts with the generic
scheam and throws away the stuff it doesn't need.  In X12 and UN/CEFACT,
some artifacts of the process (fields marked "NOT USED") remain due to
syntax constraints. In XML, the artifacts simply disappear.

Cheers,
         Bob Miller


------------------------------------------------------------------
To unsubscribe from this elist send a message with the single word
"unsubscribe" in the body to: ebxml-core-request@lists.ebxml.org