Re: [dcml-frame] Implementation Subgroup

[Tim Howes <howes@opsware.com>]

Fred, you are completely missing the point. The
point is not to produce THE implementation of
DCML. The point is to produce an EXAMPLE implementation
of DCML that will help people understand the standard,
show that the standard is useful, and encourage vendors
to produce products based on the standard.

Second, there is no conflict between defining
interfaces and creating an implementation. In
fact, you must do the first to do the second.
The advantage of doing them in a parallel, iterative
fashion is that you have a much greater chance of
actually getting your interfaces right if you
know they work via implementation.

Third, there is a long and highly successful
history of combining standards development with
implementation. Namely, the Internet. That's the
model I'd like us to follow. If you can think
of a more successful one, I'm all ears.

Fourth, any implementation we produce will be
a toy. The point is not to make something that
will compete with anybody's actual product. But
it will serve its purpose, which is education,
awareness, and validation of our ideas. If it
helps, you can think of the example implementation
as the product of one (or a couple, if other
people want to help) of the WG members, rather
than the product of the group itself, which I
agree should be the interface definition.

Does that make sense?            -- Tim

Cummins, Fred A wrote:
> Tim,
> 
> I would rather see the product vendors do implementations.
> First of all, our implementation would likely be a prototype
> that might not reflect all of the requirements. Secondly, 
> different vendors will have different implementations, and
> the interface specification should enable that differentiation.
> I also hope that if we do it right, most vendors will be
> able to adapt their products to comply rather than developing
> completely new products.  Finally, we should be able to
> specify reasonably good interfaces in much less time than
> it would take to implement a prototype with well-designed
> interfaces.
> 
> Fred 
> 
> 
>>-----Original Message-----
>>From: Tim Howes [mailto:howes@opsware.com] 
>>Sent: Tuesday, October 25, 2005 4:01 PM
>>To: Cummins, Fred A
>>Cc: dcml-frame@lists.oasis-open.org
>>Subject: Re: [dcml-frame] Implementation Subgroup
>>
>>I agree, we need to identify the interfaces. But frankly an 
>>interface in a document is not worth nearly as much as an 
>>interface combined with an actual implemtation of that 
>>interface. And since we've already defined the key data 
>>interface in the current specification, we should implement it 
>>to see if it works. If it doesn't, or it's the wrong 
>>interface, or whatever, we should sharpen
>>our pencils and try again.            -- Tim
>>
>>Cummins, Fred A wrote:
>>
>>>Tim,
>>>
>>>My expectation was to focus on interfaces to services to achieve 
>>>interoperability between products developed by different vendors.  
>>>OASIS specifications for DCML should define interfaces and product 
>>>vendors should define implementations.
>>>
>>>We should identify and specify priority interface(s) that 
>>
>>have market 
>>
>>>value and would be implemented by product vendors.
>>>
>>>Fred
>>>
>>>
>>>
>>>>-----Original Message-----
>>>>From: Tim Howes [mailto:howes@opsware.com]
>>>>Sent: Tuesday, October 25, 2005 3:30 PM
>>>>To: dcml-frame@lists.oasis-open.org
>>>>Subject: [dcml-frame] Implementation Subgroup
>>>>
>>>>Hi all. Here's what I think the implementation subgroup that 
>>
>>we talked 
>>
>>>>about on today's call should focus on.
>>>>Please send me your comments, but this is what I've
>>>>had in mind.                             -- Tim
>>>>
>>>>The implementation subgroup is tasked with creating a freely 
>>
>>available 
>>
>>>>open source implementation of a DCML- based solution to the ITIL 
>>>>configuration management problem as described by the process 
>>
>>subgroup. 
>>
>>>>The first use case implemented will be one that incorporates CIM and 
>>>>other data sources. This implementation will
>>>>provide:
>>>>
>>>>- a concrete example that furthers people's understanding
>>>> of DCML, how it relates to CIM, and the problems that
>>>> it is meant to solve;
>>>>
>>>>- example code that will encourage vendors to create
>>>> their own implementations;
>>>>
>>>>- a proving ground for changes to our use cases, the
>>>> technical definition of DCML itself, and the relationship
>>>> between DCML and other standards.
>>>>
>>>>The implementation will strive to be of actual use, but more 
>>
>>important 
>>
>>>>is its educational purpose. As such, we will strive to make it very 
>>>>easy to download and get started with (e.g., download and 
>>
>>run in less 
>>
>>>>than
>>>>5 minutes).
>>>>
>>>>Our deliverables include
>>>>
>>>>- Detailed description of what we will build
>>>>
>>>>- Detailed project plan with milestones and dates
>>>>
>>>>- The software itself
>>>>
>>>>- Documentation and other materials
>>>>
>>>>
>>