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

["Miller, Robert (GXS)" <Robert.Miller@gxs.ge.com>]

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