[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...)
Here, here! I agree completely!!!
From: Art Botterell
To: Emergency_Mgt_TC TC
Sent: 8/17/2005 8:20 PM
Subject: [emergency] PROCESS for the Future (was Re: [emergency] EDXL_DE - Notes from the meeting...)
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...
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 <email@example.com> 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
IEM CONFIDENTIAL INFORMATION PLEASE READ OUR NOTICE: