On 10/26/05, James M Snell <[EMAIL PROTECTED]> wrote: > Overly complicated. > Easy to screw up.
XOXO provides a DTD and a Relax NG schema. What's so hard about that? > 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. > Potential naming conflicts with other proposed microformats > (http://www.microformats.org/wiki/hatom). There's no naming conflict. I'm just using XOXO as defined. > 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. > >>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. > 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? > Why does it exist? Why use it? What's the difference between "editing > information" and entry metadata? Beats me. I'm just responding to feedback from the WG. What's the "real" pub:control for? > 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. > 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? > >>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. No, it says you get a partial listing of the server's choosing when you send a GET. Robert Sayre
