Re: [emergency] EDXL 2-May-2005: Distribution element : IDs

[Art Botterell <acb@incident.com>]

On May 16, 2005, at 11:52 PM, Renato Iannella wrote:

> My view is that the information about the senderID and timestamp  
> already appears, so there is no need to repeat this as part of a  
> <reference>.

There shouldn't be any repetition, because <messageReference> doesn't  
refer to the current message.  It's only used to refer to one or more  
earlier messages that are somehow modified, referenced or cancelled  
by the current one.

>> As for <sender>, perhaps I misunderstand, but I don't think we  
>> actually limit these ids to email addresses...
>>
>
> Yes we do. The document says "... in the form user@hostname..."

True, but that doesn't need to be an actual email address (e.g., it  
could be an arbitrary designator)... nor is the "user" part required  
to refer to a human.  (For clarity maybe we should change that  
pattern description to read something like "in the form actor@domain- 
name".)

Again, the challenge is to ensure uniqueness while maximizing a)  
compatibility with users' internal schemes and b) meaningfulness on  
human inspection.  While we certainly could use UUIDs in either or  
both these elements (<senderId> and <messageReference>), implementers  
would then need to deploy some sort of additional lookup mechanism to  
recover their meanings.  Guess I'm not understanding how UUIDs would  
be better.

> (BTW - we should look at WSN as a mechanisms for EDXL message  
> subscription and exchange ;-)

Certainly.  However, our goal has been to devise data structures that  
can take advantage of any available transport, including non-web- 
service mechanisms such as data broadcasts.  Maintaining that degree  
of abstraction has taken an extra level of effort, of course, but at  
least with CAP the results in terms of broad uptake have been  
gratifying.

Best regards,

- Art