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


Joseph - thanks!

I would definitely suggest we re-open it.  Defining a storage format 
without knowing what we will get back (serialization) is useless to me 
and other people implementing this technology.  It is like saying that 
we will make CC's and BIE's, but no one can ever look at them.  What 
good is that?  Even if it is to share with Human being and not machines, 
we still need to define how they will be structured etc.

Without the serialization format, no one can count on being able to view 
or use CC's and BIE's.  We _have_ to know what we will get back if we 
request an instance of either.  Otherwise, this technology is a dead end 
for application processing.

Duane Nickull  


Chiusano Joseph wrote:

>Duane,
>
>Thanks so much for your suggestions. I'll need to fulfill my obligation
>to the SC regarding our history, so I'll mention up front that the SC
>debated this topic vigorously back in June 2003, and after a very
>intense and detailed debate decided that while the creation of an XML
>serialization for Core Components is a very important factor, it was out
>of scope of our charter and should be done by another group. We decided
>instead to pursue a RIM binding.
>
>However, I'm fine with re-opening this debate given your new
>participation in our SC - in light of that, if anyone feels that we
>should reverse our decision of 6 months ago (and all of the work that
>resulted from it) please express it on our listserv.
>
>Thanks,
>Joe
>
>Duane Nickull wrote:
>  
>
>>All:
>>
>>Thanks for the welcome to the list.
>>
>>In light of the recent work to define a storage mechanism for Core
>>Components (including *CC's and *BIE's) within an ebXML Registry, I have
>>some thoughts.
>>
>>After sitting with the past threads for a while, what occurred to me is
>>that maybe we should not define the storage itself, but define the
>>serialization that will come out of the registry.  Please think about
>>this for a bit.
>>
>>1. Like UDDI, I believe that we should stick to defining the interface
>>to the object (CC) and leave the storage to the implementors.
>>
>>2. What I (among other people) really need to know is "what" we are
>>going to get back if we ask a registry to give us a core component/BIE.
>> I don't really care how it is stored as long as its' relationships to
>>other CC's and full semantics are preserved and those relationships are
>>available via the RSS.
>>
>>3. The serialization should probably be in XML format, but I am open to
>>discussions.  UML is NOT suitable although I would envision that UML can
>>be referenced from the XML serialization.
>>
>>The lack of a concrete serialization or interface to a core component is
>>holding back development of many systems.  I firmly believe that this is
>>much needed and logical step forward for ebXML CC's and BIE's.
>>
>>Duane Nickull
>>
>>--
>>Senior Standards Strategist
>>Adobe Systems, Inc.
>>http://www.adobe.com
>>    
>>
>
>  
>

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





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