PROCESS for the Future (was Re: [emergency] EDXL_DE - Notes from the meeting...)

[Art Botterell <acb@incident.com>]

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 iterations.

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) schema.   
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:

> 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
>
>
>