Luke Arno wrote:
I am writing a generic Atom Publishing Protocol client. I want to be
able to point it at any APP implementation and have it list all of the
collections available. Your choice is to require my client to scan some
arbitrary piece of XHTML hunting for specially formatted anchor tags
placed in any arrangement in the markup. My choice is to require my
client to look in a very specific place for very specific tags that tell
me very specifically what I'm looking for. Regardless of how my client
displays the results, convince me, using a clear use case scenario, that
your approach is better and helps to ensure interoperability between APP
client and server implementations.
I like your use of colorful language to paint parsing
based on a few simple explicit queues as a real labor.
"hunting" - LOL. You will never catch those cotton-pickin
microformats without camouflage and dear urine.
Your choice is to limit innovation to spare you an
exceedingly trivial effort.
Straw man. You're framing my argument as being against innovation when
I have very specifically and very clearly articulated that the core spec
should NOT include any language forbidding hierarchical arrangement of
collections. Rather than trying to pick apart a single word in my note,
answer the question.
ALL I am asking for is use cases. I am NOT asking for a proposal on how
my client can handle your proposal. I want to know WHY I should even
care about your proposal.
And yes, I've read all the Pace's and all the notes. I have yet to see
my request for use cases addressed.
Your request is absurd to me. It is absurd to look
for use cases to justify *not* placing constraints
on an architecture. That is a negative proof fallacy.
It is absurd to propose and argue for a solution to a specific technical
solution to a problem that has not yet been demonstrated to exist.
That's a Bad Spec Writing Fallacy. What I am asking for is a use case
that demonstrates why your specific proposed technical solution is
better than what has already been put on the table.
As for the assertion about it being absurd to look for use cases to
justify not placing constraints, that in itself is absurd. Protocol
constraints play an invaluable role in the success of the protocol. The
choice to not add a constraint to a given aspect of the protocol can be
as important as the choice to add a constraint. For example, let's
remove the constraint that APP MUST use HTTP; I mean hey, somebody in
the future *might* want to use some other transport protocol to edit Web
resources right? Why should we restrict innovation by requiring Atom
implementations to use HTTP? It doesn't matter if a) the vast majority
of implementations will be using HTTP and b) I can't point to any
non-hypothetical use cases in which the use of other protocols would be
justified because hey, it's absurd to ask me to justify not placing a
constraint to use HTTP.
Someone may want to create a client and server
that allow users to treat their collections and
members (conceptually) like files and folders, yet
still inter operate with existing clients and servers.
Finally, a use case... albeit a hypothetical one, but still a use case.
Let's chew on it.
Help me to understand your proposal. Explain to me how your proposed
solution would work given this case and why it is technically superior
to the status quo? Apply the 80/20 rule to this case and provide a
clear demonstration why the core APP spec should do anything more than
not forbid hierarchical arrangements of collections.
Also, while your busy accusing me of seeking to limit innovation, point
to anything that I have said throughout the course of this discussion
that demonstrates that I think folks shouldn't be able to do this kind
of thing.
Why close the door on such an innovation?
Because you are hung up on some stiff parsing
style and wont exert the trivial effort required to
use a slightly different parsing style?
No one is closing any doors. I'm only asking you to defend your
position with tangible examples and use cases that demonstrate why we
should adopt your Pace. Remember, you are the one arguing that there is
a need to make a specific change to the spec. You throwing around
claims that I am somehow seeking to limit innovation or that I must have
some absurd quasi-religious aversion to XHTML and microformats is simply
not good enough. I've already stated (on many occasions) that I
couldn't care less about the specific format used for this stuff -- at
least not at this point.
- James
