OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

emergency message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

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

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]