[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]
Powered by eList eXpress LLC