Re: Use Cases

Hi Mark,

just came across this[1] earlier related exchange; a good chance to  
restate my question in other words.

You wrote:

"Well, there's got to be other information provided with the form that
your app can use to decide if it's going to take any of the actions
described by the form."

When you say "information [...] that your app can use to decide", do  
you refer to the time the app is built (or configured) or to the time  
the app actually consumes the form in its runtime interactions with  
the service.

IMHO it should be the latter - I think the former leads to  
uneccessary coupling.

Jan

On Jun 10, 2006, at 5:18 PM, Jan Algermissen wrote:

>
>
> On Jun 9, 2006, at 4:18 AM, Mark Baker wrote:
>
>>
>> HTTP already provides some "design time" information too.  OPTIONS
>> responses, for example.  The Allow response header.  Probably other
>> things.
>
> Maybe some agreement on terms is necessary here. I understand  
> design time information to serve as a contract between client and  
> server that is guaranteed to be stable at runtime. IOW, a contract  
> that can go into the design, usually by more or less hardcoding it.
>
> Having said that, could you clarify wheather why you consider  
> OPTIONS and Allow to provide design time information in *that* sense.
>
> To put this in other words: Since the server can change at any time  
> the response it sends for a given OPTIONS request, of what use is  
> such a response rearding any conract between client and server?
>
> Jan
>
>>
>>>  It would help with things like
>>> tooling and testing and automation, too.
>>
>> I think that's part of what we're trying to determine.  Having  
>> built a
>> handful of machine-to-machine Web based systems, none of which needed
>> a "description language" (nor would they have benefitted from one,
>> IMO), I'm skeptical that there's a big enough problem here that
>> requires a new standard (rather than reusing, say, XForms).  But I'm
>> happy to be convinced otherwise.
>>
>>> > IMHO, HTTP and the shared understanding of a MIME type *and* the
>>> > intention of the client developer at design time are sufficient to
>>> > actually implement the client side - if the design time
>>> > expectations do not hold at runtime this will be detected at
>>> > runtime. (I do not consider this a problem since there cannot be a
>>> > design time constraint on the runtime in a distributed system
>>> > anyhow so you allways need to check and expect insifficient data)
>>>
>>> My experience differs.  When building a heterogeneous distributed
>>> system, I'd like to have a contract that operates at a higher level
>>> than a MIME type, so that when things break, you can finger-point
>>> constructively.  -Tim
>>
>> Sorry, I don't understand what you mean by that.
>>
>> Mark.
>>
>
>

Received on Sunday, 11 June 2006 10:01:16 UTC