[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: Re: The role of context in the re-usability of Core Components andBusiness Processes - OR Say What???
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
Powered by eList eXpress LLC