Re: Why MD5 Headers are Imperative

>
>You might well have identified problems in APP, you seem to believe it 
>vehemently. But your arguments are not cogent to me.
>

Thanks for putting it politely, Bill.

>
>I'll speculate some. You have an identity and data modeling model issue 
>that APP can't help you with. Or HTTP, come to think of it.
>

Works beautifully when I only implement HTTP and Atom Format, APP breaks it. 
This makes it not a data modeling issue, nor an access issue with HTTP.  Not 
my fault APP can't interact with a valid Atom feed, by restricting itself to 
only the Atom ID <entry> that's been most-recently modified, but not the 
duplicate with an older <updated> value.

My extension to APP, whatever one may think of it, solves the problem by 
fixing APP -- not changing my valid assumptions -- resulting in a system 
which operates beautifully and allows me to edit any <entry> in a valid feed.

The only drawback, is APP clients which don't comply with my extension will 
be treated as feed readers.  So I have a real hard time seeing this as an 
issue with anything other than APP...

>
>I note you haven't said what the resource denoted by
>
>   http://example.com/2006/aug/9.01.atom
>
>is. You need to decide what that URI denotes, and what representations 
>will be issued. If you need to change the state of a resource that is a 
>xquery file, you need to give it a URI. If accessing that URI returns a 
>query result, and not the source of the query, that is squarely your 
>problem to deal with. In short you need to persuade me you are not 
>playing Games With URIs*, and swapping out referents based on the 
>internal needs of your application.
>

http://example.com/2006/aug/9.01.atom is the XQUERY file URI.  This is one 
resource.  See where I get a little confused with semantics?  My resource 
doesn't vary per user, it executes for some while allowing code access to 
others.  I hear what you're saying about referents specific to internal 
needs, but WebDAV is clearly a different need than any other so I'm not sure 
where what I've done is bad -- WebDAV clients can only manipulate the 
XQUERY, they aren't fooled into thinking it's an Atom file.

Is this really different from responding to a URI request with the HTML code, 
like if it's an APP client, vs. rendering the HTML document for browsers when 
the same URI is requested?  Execute for some, display code for others...

I could also expose the XQUERY at this URI:

https://example.com/2006/aug/9.01.atom

But, it's still an XQUERY with an .atom extension.

-EJB

>
>cheers
>Bill
>
>* Tip of the hat to Wittgenstein
>
>