OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

emergency message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: <explicitAddress> (was Re: [emergency] EDXL_DE - Notes from the meeting to help with minutes and issues list.)


As I recall, the purpose of <explicitAddress> was to allow the  
inclusion of, well, an explicit address.  We didn't want limit it to  
any particular addressing scheme, so I don't think constraining it as  
a URI serves the intent.  Maybe we need to provide a pointer to the  
addressing scheme being used... even if it might be one that not all  
routers or recipients know about, in which case they'd know to ignore  
the related address(es)... in order to disambiguate it.

In any event, this will be designated Issue #7 in the next version of  
the Issues List.

- Art



On Aug 17, 2005, at 8/17/05 4:58 PM, Michelle Raymond wrote:

> 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
>>
>>
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe from this mail list, you must leave the OASIS TC that
> generates this mail.  You may a link to this group and all your TCs  
> in OASIS
> at:
> https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
>
>
>



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]