Next in thread →
Next in month →
RE: [emergency] PROCESS for the Future (was Re: [emergency] EDXL_DE - Notes from the meeting...)
Title: RE: [emergency] PROCESS for the Future (was Re: [emergency] EDXL_DE - Notes from the meeting...) Here, here! I agree completely!!! Patti -----Original Message----- 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... - 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 <> 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 IEM CONFIDENTIAL INFORMATION PLEASE READ OUR NOTICE: http://www.ieminc.com/e_mail_confidentiality_notice.html
Next in thread →
Next in month →