[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. 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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]