OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

ebxml-core message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]


Subject: Section 5.5.


One of the complaints of the latest review team concernts section 5.5 of the
Context and Re-usability of Core Components document, which currently reads:

"5.5 Building Business Documents
 Business documents are built by drawing on the repository "library" of
components. The  context descriptors that are registered for each component
are used to select the  appropriate context constrained information entities
for the business document that is  being built. These values would be the
same as values found in a business process model  that informs the
contextual use of the core components.

 If no appropriate context constrained information entity exists, a new one
must be  created, according to the principles described in the previous
section, and ideally using an  existing stereotype. Registration of the new
process specific information entity adds to  the range of available context
descriptors. "

A related complaint covers Section 5, Document Assembly, of the Document
Assembly and Context Rules

I would propose the following alternative text be used for both sections:

"A business document consists of a set of information entities that are
designed to facilitate a named business process. Wherever possible these
information entities must be derived from registered core components by the
application of a regisered set of contextual constraints. Where no suitable
core component exists an application-specific component must be declared as
part of the context rules created to generate the schema/DTD that will be
used to validate the contents of the business document. Application-specific
components should be registered in a registry so that they can be accessed
by other applications. Where an application-specific component is likely to
be of relevance to a large number of business documents it should be
reviewed for inclusion in a registry of core components.

Whenever core component definitions are stored in a core component registry
they will have associated with them, as metadata, one or more classification
nodes, as defined in the local classification registry. Users wishing to
identify an existing core component within a registry will select those
classification nodes that they consider relevant to thier business process,
and request that the repository returns a list of core components that have
been associated with the selected set of classifications, together with
details of context rules that have previously been recorded by the registry
as being used to constrain the use of the core component in associated
contexts.

The set of core components used by a specific business process to create a
business document should be recorded in a registry as an assembly of core
components to be used within a specific context. Each such assembly should
have associated with it, as metadata, a list of classification nodes that
identify the contexts in which it is intended to be applied.

To meet a specific business process a business document may need to apply
some additional constraints, or some extensions, to a core component. The
Type Use Rules to be applied in a particular context may rename the
component, restrict or extent the subcomponents allowed within an aggregate,
or define a datatype constraint on the contents of the components. Type Use
Rules should be registered, and should be associated with the set of
registry classification nodes that identify the business process the
business document is intended to meet the requirements of."

Martin Bryan




[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]

Search: Match: Sort by:
Words: | Help


Powered by eList eXpress LLC