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

 


Help: OASIS Mailing Lists Help | MarkMail Help

regrep-cc-review message

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


Subject: Re: [regrep-cc-review] Re: Methodology - OWL


I volunteer.

Duane

Chiusano Joseph wrote:

>All,
>
>We discussed this topic (XML serialization of Core Components) on our
>last Registry TC call, and the consensus was:
>
>- It needs to be done
>- It should be done within the Registry TC
>- Furthermore, it should be done within the Core Components Review SC
>
>So at this point, we're looking for someone who would like to lead this
>work while I continue to drive forward with the storage representation.
>If anyone would like to volunteer, please let me know.
>
>Thanks,
>Joe
>
>Chiusano Joseph wrote:
>  
>
>>Here's an update on this for all (including serialization in our
>>efforts):
>>
>>I have run this by Kathryn, and we've decided to add it to the agenda of
>>our next Registry TC call. I'll send an update to the list after it's
>>discussed.
>>
>>Joe
>>
>>Duane Nickull wrote:
>>    
>>
>>>Joseph:
>>>
>>>I would word the choices as this and call for a vote for #1 or #2:
>>>
>>>1. This group should take on the task of defining the serialization for
>>>Core Components and BIE's.  This will enable them to be used and
>>>retrieved from a registry or anywhere else.  This work will be done in
>>>addition to defining the storage format.  The group will sort out the
>>>details later of what dependencies may exist between these two tasks.
>>>
>>>or
>>>
>>>2.  This group will not be involved with defining a Core Component or
>>>BIE serialization.  There is no need for anyone to use CC's or BIE's or
>>>another group should be formed to tackle that responsibility.
>>>
>>>I propose that you, as chair of this group, call for a vote.  I do not
>>>see any benefit to define a serialization in absence of a storage format
>>>so saving and using the existing work is valid.
>>>
>>>Thanks
>>>
>>>Duane Nickull
>>>
>>>Chiusano Joseph wrote:
>>>
>>>      
>>>
>>>>Excellent points - I think a vote would be best. However, I'm still not
>>>>certain about what is being proposed, and we probably shouldn't have a
>>>>vote until this is solidifed. Please let me know which of the 2 choices
>>>>you propose:
>>>>
>>>>(1) That we not define storage for CCs (undoes all of our work thus far)
>>>>(2) That we define storage for CCs, and additionally an XML
>>>>serialization
>>>>
>>>>Thanks,
>>>>Joe
>>>>
>>>>Duane Nickull wrote:
>>>>
>>>>
>>>>        
>>>>
>>>>>Joseph:
>>>>>
>>>>>How about a negative opt-out response instead?  If anyone feels that
>>>>>this should NOT be done in our TC, they can express why to this list.
>>>>>
>>>>>Can we assume the work if no one opposes it?
>>>>>
>>>>>Duane
>>>>>
>>>>>Chiusano Joseph wrote:
>>>>>
>>>>>
>>>>>
>>>>>          
>>>>>
>>>>>>Thanks so much Duane. In terms of the SC, we still have not received any
>>>>>>feedback indicating any agreement whatsoever that we should include
>>>>>>serialization in our work. If anyone feels that we should, please
>>>>>>express this on our listserv. Unless there are responses, we can't have
>>>>>>a sense of what the SC believes is the best course of action.
>>>>>>
>>>>>>We also have not yet clarified whether or not the serialization would be
>>>>>>in place of the storage work we have done so far, or in addition to.
>>>>>>Let's also please clarify this point as well.
>>>>>>
>>>>>>Looking forward to your responses...
>>>>>>
>>>>>>Joe
>>>>>>
>>>>>>Duane Nickull wrote:
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>            
>>>>>>
>>>>>>>All:
>>>>>>>
>>>>>>>I would propose that we use a RUP/UMM type methodological approach to
>>>>>>>our work in this area.
>>>>>>>
>>>>>>>1. gather stakeholder requirements, technical requirements of what is
>>>>>>>needed in the Serialization.
>>>>>>>
>>>>>>>2. define the serialization first.
>>>>>>>
>>>>>>>3. work backwards based on the serialization to determine what must be
>>>>>>>present in the storage format.  IMO - the serialization requirements
>>>>>>>will create dependencies on the storage format.
>>>>>>>
>>>>>>>To me,  this is the correct and logical way to approach the problem.  I
>>>>>>>hereby volunteer to take a stab at the first draft of #1 above
>>>>>>>(requirements for the serialization).
>>>>>>>
>>>>>>>Duane Nickull
>>>>>>>
>>>>>>>--
>>>>>>>Senior Standards Strategist
>>>>>>>Adobe Systems, Inc.
>>>>>>>http://www.adobe.com
>>>>>>>
>>>>>>>To unsubscribe from this mailing list (and be removed from the roster of the OASIS TC), go to http://www.oasis-open.org/apps/org/workgroup/regrep-cc-review/members/leave_workgroup.php.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>              
>>>>>>>
>>>>>>To unsubscribe from this mailing list (and be removed from the roster of the OASIS TC), go to http://www.oasis-open.org/apps/org/workgroup/regrep-cc-review/members/leave_workgroup.php.
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>            
>>>>>>
>>>>>--
>>>>>Senior Standards Strategist
>>>>>Adobe Systems, Inc.
>>>>>http://www.adobe.com
>>>>>
>>>>>
>>>>>          
>>>>>
>>>>
>>>>        
>>>>
>>>--
>>>Senior Standards Strategist
>>>Adobe Systems, Inc.
>>>http://www.adobe.com
>>>      
>>>
>>To unsubscribe from this mailing list (and be removed from the roster of the OASIS TC), go to http://www.oasis-open.org/apps/org/workgroup/regrep-cc-review/members/leave_workgroup.php.
>>    
>>
>
>  
>

-- 
Senior Standards Strategist
Adobe Systems, Inc.
http://www.adobe.com





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