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>]

William,

Now we're really getting somewhere.  See Martin Bryan's response I've
snipped and inserted below.


>>Is this being used to build message schemas
>> (as opposed to document instances) on the fly?

>Not on-the-fly but on-demand. When a new process or context for a
particular
>process is identified then a schema/DTD for validating messages in that
>context has to be prepared.

Following this advice to its ultimate conclusion, there should no longer be
a need for optional fields, since context will have filtered out these
fields in constructing the context specific schema.  Just think what a great
simplification this represents!

Of course, on the other hand, maybe (as you suggest) the complexities of
business life will prevent our ever reaching this conclusion.  That is, some
context rules may be useful in constructing schemas.  Other context rules
will only have application relevance in constructing and validating document
instances.  You may choose to question (I would) why one would bother to
keep creating context-specific schemas, when the end applications are
themselves going to have to deal with the rest of the context rules.  Why
not just use the generic 'global' schema, and apply all of the context rules
within the application?

Actually, I do support the creation by industry groups of industry specific
schemas. But like you William, I find it counter-productive to extract all
manner of context rules for all manner of industries and associate these
rules with individual core components, with some expectation that an
algorithmic process will then be able to construct a Schema for my industry
group (want to bet it will need tinkering?) that I could have built and
absolutely controlled without enduring such complexity.

Cheers,
         Bob