Robert Sayre wrote:
I still haven't seen any demonstrated hard requirement for collection
nesting.
That's because you refuse to acknowledge the problem. You have a list
of blogs per account, and sub collections related to each one.
No, it's because I haven't seen any demonstrated hard requirement for
collection nesting. I fully recognize the need for multiple collections
per blog; that does not mean that a media collection has to be nested
"arranged hierarchically" under the entry collection as the example in
your draft demonstrates.
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.
Another process objection. I asked you for technical feedback, not
bureaucratic feedback.
And the part about capabilities discovery being mentioned but never defined?
the definition pub:control is underspecified;
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 do you want to know? I've never seen a definition for the
element, so I'm not sure how I could have underspecified it.
You haven't read
http://www.intertwingly.net/wiki/pie/PaceCollectionControl ?
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.
It's obviously a child of atom:entry. Where else would it go?
Obvious? I tend to prefer not making assumptions as to what may or may
not be obvious to the folks who will be implementing the spec. There
are lots of places pub:control could go.
Status codes are fine, but how is other error information provided (e.g.
a human readable description of the specific failure that occurred)?
In the message body. See RFC 2616.
And what representation format should be used for that error
information? What information should be included? Should the error
response format be defined as part of the core? 2616 only says that
error information SHOULD be returned, it provides no other clues. "See
RFC 2616" is not a good enough answer.
Does a 5xx response really mean that the request has failed or could it
mean that the status of the request is unknown?
Failed. See RFC 2616.
Should there be any
discussion about failure recovery?
RFC 2616 provides the normative direction here. Or do you think we get
to reinvent it?
Ok, referencing 2616 is perfectly acceptable of course, but, gee, it
sure would be nice if such references were documented in the draft.
What is obvious to you may not be obvious to folks implementing your draft.
- James
