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
