Subject: Re: [emergency] EDXL_DE - Notes from the meeting to help with minutes and issues list.
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 <firstname.lastname@example.org> 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 > > >