Robert Sayre wrote:
I believe the XOXO based
service outline is entirely the wrong approach and is underspecified;
Why. Give *technical* reasons. I really don't care what you believe. I
do care about technical problems.
Overly complicated.
Easy to screw up.
I still haven't seen any demonstrated hard requirement for collection
nesting.
Potential naming conflicts with other proposed microformats
(http://www.microformats.org/wiki/hatom).
Capabilities discovery is mentioned but never defined.
It's unclear (to me at least) as to whether the contents of a wiki page
(http://microformats.org/wiki/xoxo) can be normatively referenced.
the definition pub:control is underspecified;
Why. What needs to be added?
For one, an element definition. The current text ("The pub:control
element is used to persist editing information and contains arbitrary
markup") tells me nothing useful about how the element is defined, what
it contains, what it is used for and how the information within it
should be handled or even where the heck the thing is supposed to go.
Why does it exist? Why use it? What's the difference between "editing
information" and entry metadata?
there is inadequate
treatment of failure conditions and error reporting;
What's the technical problem you are worried about?
Status codes are fine, but how is other error information provided (e.g.
a human readable description of the specific failure that occurred)?
Does a 5xx response really mean that the request has failed or could it
mean that the status of the request is unknown? Should there be any
discussion about failure recovery?
and member listing is underspecified.
How's that? I was waiting for mnot to sort out the link relations. The
sync stuff, whether by date or count, in the WG draft is hopelessly
naive.
Exactly how the URI construction should play out is still a subject that
I'm undecided on. Either way, your spec says does not say anything
useful about *how* partial listings are requested or processed by the
client.
- James
