Re: [emergency] EDXL_DE - Notes from the meeting to help with minutes and issues list.

[Michelle Raymond <michellearaymond@gmail.com>]

Hmm...
This raises two thoughts:

1.  If the intent of <explicitAddress> is to provide data that can
lead to delivery of information contained in the <contentObject>, then
it had best be some actionable piece of data.  It really could be an
email address a link to a web form or even a phone number.  However
this raises the question of the type. Currently the type for the
<explicitAddress> is xsd:anyUri

****OOOOHHH! I take that back.  The Data Dictionary has it as a 'uri',
but the schema has it as a 'string' and I go by the rule "The schema
rules trump the documentation, as it is the rules against an instance
will be validated."   (I'll change the Data Dictionary type to match
the schema).

Well, it still raises the question of type.  How will the processor of
the Distribution Element know what to do with the content of the
string in <explicitAddress>.

2. I think your suggested documentation for <senderID> is good, and
better used here than in <explicitAddress>.  What it doesn't include
is how we may 'understand' the sender's identification from the
<senderID> string.  The use of the domain-name extension gives us a
partial resolution to that understanding.

Best regards,

Michelle




On 8/17/05, Kon Wilms <kon@datacast.biz> wrote:
> On Wed, 2005-08-17 at 16:58 -0500, Michelle Raymond wrote:
> > Proposal: Leave the definition as "Unique identifier of the sender."
> > Modify the comments to reflect this is not a formal "email address".
> 
> Why not just make the definition the same as explicitAddress, but for
> senders and not recipients, i.e.:
> 
> > Definition  The unique identifier of the sender.
> > Comments  Uniquely identifies human parties, systems, services, or
> > devices that are all potential senders of the distribution message.
> 
> Cheers
> Kon
> 
> 
>