[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...)
Art, This makes perfect sense and should make the process more efficient. This is exactly the process sequence we followed developing the draft Resource Messaging spec :-). Tim -- Tim Grapes DHS Disaster Management Mount Weather: (540) 542-3239 Mobile: (703) 304-4829 tgrapes@evolutiontechinc.com tim.grapes@associates.dhs.gov On Wed, August 17, 2005 10:26 pm, Rex Brooks said: > Seems like a good thought to me, Art. > > Ciao, > Rex > > 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 >>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 >>> >>> >> >> >>--------------------------------------------------------------------- >>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 > > > -- > Rex Brooks > President, CEO > Starbourne Communications Design > GeoAddress: 1361-A Addison > Berkeley, CA 94702 > Tel: 510-849-2309 > > --------------------------------------------------------------------- > 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]