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: Re: Tags and semantics ( was Dotted Names)



Of the many messages under this heading during my absence over the last week
the following fragment seemed to me the most relevant
>
> 1) The core components willnot hold the complete set of semantics
> sent in messages, some of this will come from the application of context
> rules.  This means that any message that has had context applied will have
> to be 'explained' to both the sender and the receiver in order that they
> interpret it in the same manner.

What everyone seems to be forgetting is that the meaning is not in the
message, its in the agreement to use a particular type of message. ebXML is
designed to allow application specific components to be used alongside core
components. Until an agreement has been reached on the meaning of these
components then message interchange cannot safely take place.

There is absolutely no need for either core component long names or UIDs to
appear in individual message components. All that is needed is a means
whereby message components can be related to UIDs, and via the UIDs to their
formal semantics, whenever those components are derived from a registered
object.

When context is applied to a core component to create a "message specific
component" in a schema or DTD the relationship between the message component
and the core component can be recorded, as part of the formal definition of
the message model in the DTD/schema, as a fixed property of the XML object
type. So, if I choose to use the Party core component to create context
specific elements such as Purchaser and Supplier then I record in my
DTD/schema the relationship:

<!ELEMENT Purchaser (Identifier, Name, Address)>
<!ATTLIST Purchaser ebXML:UID CDATA #FIXED "00085" ebXML:longName CDATA
FIXED "Party">
<!ELEMENT Supplier (Identifier, Name, Address)>
<!ATTLIST Supplier ebXML:UID CDATA #FIXED "00085" ebXML:longName CDATA FIXED
"Party">

The fact that two elements in a DTD/schema, or different elements in
different DTDs/schemas share the same fixed attributes tells both the
sending and receiving systems that they contain the same type of data, and
that this type of data is one that has been registered by ebXML, in the hope
that the system is already ebXML aware and therefore can automatically map
data to it. If it is not the namespace identifier for ebXML tells the system
where it should go to obtain resolution of the meaning of the UID or
longName properties of an element.

Once this is done individual messages do not need to carry this information:
it is fixed information that is available to all parties of the CPP as
previously exchanged data.  The idea that individual messages should be
encumbered with registry look up information on every field is sheer madness
to me.

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