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


Help: OASIS Mailing Lists Help | MarkMail Help

ebxml-transport message

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

Subject: RE: [Fwd: RE: on the issue of PartyId]

Message text written by Scott Hinkelman/Austin/IBM
Correct -that was the original intent of Context.

I would say that the *non-existance*  of type tells you that the party id
is a URI (which has context).
It *existing* indicates that the party id is a value that is user-defined,
and the value of type is also
user-defined, which may or may not indicate context for the value of party

The question then becomes: do we want to dictate that the value of the
optional attribute must
indicate a domain scoping?

Scott Hinkelman

Scott - does this circular discussion not end back where I posted, that
using the RegRep to locate that domain and classification is the 
obvious choice?  And that the reference into the Registry to the 
context of the element/attribute pair is an other obvious mechanism?

So as you note - if its unqualified - its a URI.  If it is qualified - then
that qualification semantics should be in the Registry - and that
Registry can be indicated by a namespace or similar already in
the transport header details.

For reference here's the code again:

Thanks, DW.

<!ATTLIST PartyId 
                      type CDATA #REQUIRED
                      qic CDATA #FIXED 'TRP01001'>

Where the qic reference TRP01001is a GUID for 
PartyID that points to the definition of PartyID in the element
(core component) layer in the Registry, and within that
 you can qualify the classification system that 'type' is using.

This is the best of both worlds, the ability to have a 
well defined behaviour, but have it extensible.

[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