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: Re: [emergency] PROCESS for the Future (was Re: [emergency]EDXL_DE - Notes from the meeting...)

Seems like a good thought to me, Art.


At 6:20 PM -0700 8/17/05, Art Botterell wrote:
>Just a thought on process...
>We seem to be working on the DE along two 
>not-always-exactly-parallel tracks: the Data Dictionary / Object 
>Model track and the Schema track.  In the future might things be 
>clearer if we were to develop one document at a time and then use it 
>as the basis for the next?  
>Even if that meant we had to iterate based on experience downstream, 
>at least we'd be doing a series of distinct, well-documented 
>The sequence we used for CAP moved from the broadest to the most 
>specific: 1) requirements and use cases, 2) data model, 3) data 
>dictionary (human readable and discussable), and finally, 4) 
>Each document was a more detailed expression of the previous one, 
>and by the time we got to the schema, the design questions had been 
>resolved and it was basically just a coding task (which as we've 
>seen can be challenging enough.)
>Doing it the other way around might be possible as well, I suppose.  
>But regardless of what sequence we choose, I'd like to suggest that 
>a "sequential/spiral" process might be more manageable and possibly 
>a bit less confusing than what could turn into a "massively 
>parallel" undertaking as the EDXL family of projects grows.
>Just a thought...
>- Art
>On Aug 17, 2005, at 8/17/05 4:58 PM, Michelle Raymond wrote:
>>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,
>>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.
>>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
>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

Rex Brooks
President, CEO
Starbourne Communications Design
GeoAddress: 1361-A Addison
Berkeley, CA 94702
Tel: 510-849-2309

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