Re: The role of context in the re-usability of Core Components andBusiness Processes - OR Say What???

[Martin Bryan <mtbryan@sgml.u-net.com>]

Bob

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

I'd still want some optional fields, because I'd want one message type per
process, but sometime whether a field is required or not is dependent on the
message contents

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

I think there is a trade-off to be made between those context rules that you
know will always be dependent on the process/industry/etc and those that you
can't determine until you know the actual transaction that needs to take
place. I had presumed that we would need a constraint language for
expressing the latter type of constraints, but this has been "thrown out
with the bath water".
>
> 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.

The problem is remembering the rules that were applied each time you go
through this process. Part of the philosophy is that the Assemble and
Context Rules entries become records of what rules were used to create the
schema/DTD. Given that there is no way of determining the form of the
document model created by the processes that use these files, the only way
to formally define how the document model was created would be to record the
rules applied. When you have done that then anyone who wants to apply the
same, or a similar set, of rules can do so with the minimum amount of work.

Martin