[occi-wg] On repainting the bikeshed at the 11th hour...

[Sam Johnston]

On 5/8/09, Benjamin Black <b at b3k.us> wrote:
> On Thu, May 7, 2009 at 2:42 PM, Sam Johnston <samj at samj.net> wrote:
>
>> Ben,
>>
>> An unimplementable specification is as useless as teats on a bull... I
>> do think it's important that we bear the developers in mind where
>> possible as if it's easy to develop for it's more likely to be used
>> extensively.
>
>
> I agree, yet don't understand how it applies to anything I've said.  Are you
> really suggesting that using JSON would result in a specification that is
> "unimplementable"?

No, I'm just saying that the two things need not be firewalled.
Separating the protool from the model is justifiable however.

>> I'm going to assume you know what atom looks like up close and
>> personal as I'm confined to an iPhone for now so my demoing ability is
>> limited... if we leave the content element well alone then it is no
>> more complicated than any XML based domain specific language we would
>> create, especially if we keep it flat and/or limit ourselves to what
>> is possible in text and json.
>
>
>> Further, these alternative transforms need be nothing more than
>> convenience formats for writing shell scripts and web interfaces...
>
>
> And we end up right back in the space I described in an earlier email:
> either we force all implementations to implement all formats or we guarantee
> the production of incompatible, fully compliant implementations.  Riding the
> fence just produces a sore bottom.  Make a choice.

No we don't - provided they implement the main format the rest is just
icing on the cake. A single line cron job won't understand json either
but that's not to say we should drop to the lowest common denominator,
or that we shouldn't support this use case given we can trivially.

>> and by providing ready made transforms they need be no more work for
>> implementors. If an implementor wants to render direct to PDF for
>> reporting then so be it. If they choose not to provide this extra
>> functionality then let the market decide. So long as we focus on one
>> primary format we're fine.
>>
>> Sam
>>
>
> "If we don't do all the complex stuff for which XML-based systems are
> notorious, we'll be fine".  There is a first time for everything.  I'm not
> going to hold my breath, though.

Have you seen the XML samples in the wiki or that generated by
http://occiteat.appspot.com? Granted I need to add
actuators/controllers and attributes like <mem>4096</mem> but you can
already see the structure is clean.

Sam