[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: RE: Long Tags Codes etc. again
|
There
seems to be a lot of good requirements in this thread. Maybe a view to an
existing implementation would be of assistance.
The
structure associated with Tags should be in response to requirements.
There have already been many requirements expressed with respect to message
construction, most having to do with proper encapsulation, reuse, and matching
to enterprise specific representations.
When
Edifecs was presented with the task of constructing RosettaNet guidelines in
1999, we were faced with the same basic set of requirements. We applied
object philosophy to these requirements and came up with the structure in the
attached document (based on our existing standards construction tools and
experience).
Note
that any one XML block (block defined as being within a tag hierarchy)
represents a BusinessDataEntity (BDE). These BDEs are reusable
information structures, and represent business objects. These
BusinessDataEntities are specialized in one of the following
subclasses:
- FundamentalBusinessDataEntity(FBDE): has a data
representation (min/max/pattern) and no composite tags.
- QuantativeFundamentalBusinessDataEntity
(QFBDE) contains a measurement and references a system of
units
- CoreComponent is a reusable structure that
represents a property and does not represent an identifiable business
object (uniquely identifiable instance)
- CommonBusinessObject is a reusable structure
that represents an identifiable business object (e.g. product, factory,
etc)
- UseAggregation is a structure related to a
specific use of a set of objects and properties
- DocumentSegment is a structure which
encapsulate a section of a document for reuse, validation, or processing
requirements
- Document is a structure which encapsulates a
document which must be complete to be valid in a business
context.
Note
that BDE, FBDE, and QFBDE are RosettaNet specific names. In the attached
diagram these are referenced as Entity, FundamentalEntity, and
QuantitativeFundamentalEntity.
Note
that FBDE, QFBDE, CoreComponent, and CommonBusinessObject exist across use case
boundaries. Note that UseAggregations will always be bounded by some high
level use case.
The
other concept that should get first class status is that of Role. When a
block has a specific use in a context, that does not create a new block, it
creates a role for that block. For instance a seller is a Role for a
Party. The Party block should clearly identify that it is a representation
of a Party entity, so that any interface able to deal with parties can process
it without special coding. Calling it <SellerParty> clearly defeats
that requirement.
<PurchaseOrder>
...
<seller>
<Party>
<Id>
</Id>
<Name>
</Name>
...
</Party>
</seller>
...
</PurchaseOrder>
For
compliance with UML, the role starts with a lowercase, while an entity
starts with uppercase.
This
type of structure, and the ability to specialize it as described in the
accompanying diagram is critical to consistent construction and
use.
The
point is that roles allow clearly labeled and constructed reusable blocks, and
that subclassing the compositional blocks allows clear guidelines that can ease
construction of efficient interfaces.
Sorry
about not offering this sooner, I was focusing on the process side
:-)
John
-----Original Message----- From: CRAWFORD, Mark [mailto:MCRAWFORD@lmi.org] Sent: Tuesday, April 17, 2001 9:52 AM To: 'ebXML Core' (E-mail) Subject: RE: Long Tags Codes etc. again
|
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC