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

[David RR Webber <Gnosis_@compuserve.com>]

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

Type:
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
id.

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.
==========================================

<!ELEMENT PartyId (#PCDATA)>
<!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.