[Fwd: draft-reschke-http-addmember-00]
(fyi) Original Message ... To: [EMAIL PROTECTED] ... Hi, recently different communities (caldav/groupdav, atompup (protocol part)) have been discussing how to use HTTP to author new resources when the URL namespace is completely server-controlled, thus PUT just doesn't fit well. A simple approach would be to define a new HTTP method which is *almost* like PUT, except that the server chooses the URL to create (and returns it in the Location header). I've submitted a first draft as draft-reschke-http-addmember-00. Note that it also contains an appendix covering possible alternative approaches. Feedback appreciated, Julian HTML version: http://greenbytes.de/tech/webdav/draft-reschke-http-addmember-00.html Latest edits will be at: http://greenbytes.de/tech/webdav/draft-reschke-http-addmember-latest.html -- green/bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760
Re: PaceLinkRelVia
+1 We are going to have a registration process, so undoubtably this will be registered anyway, but we might as well as include it in the initial batch. - Sam Ruby
Re: PaceLinkRelVia
+1 Robert Sayre
Re: atom:entry elements MUST contain an atom:summary element in any of the following cases
I don't think that accessibility is optional. It isn't a profile, it is a requirement. Maybe summaries are optional, but not because accessibility is optional. wunder --On February 14, 2005 8:48:08 PM -0800 James M Snell [EMAIL PROTECTED] wrote: At the risk of beating the PaceProfile drum to death, I would think that an Accessibility profile could be used to specify specific requirements for accessible feeds. The core could do exactly as you suggest below -- not require summary. -- Walter Underwood Principal Architect, Verity
Re: atom:entry elements MUST contain an atom:summary element in any of the following cases
James M Snell wrote: Robert Sayre wrote: Yes or No: Is asking what capabilities existing XML-RPC protocols provide is a productive way to set the limits of the Atom Protocol? Of course not. I for one don't really give a rip what the existing XML-RPC API's currently provide or don't provide. I certainly care about what they provide, but my proposal was based on problems I had with the deployed draft-gregorio-09 protocol. Sam once told me a story about a group of important open source developers having an argument where all sides contended their suggestion was the simplest thing that could possibly work. I see a similar problem emerging around the catchphrase YAGNI with regard to the protocol. Here are some observations I've made: All of the existing XML-RPC APIs provide some sort of querying, yet it's been said that avoiding querying would be good. YAGNI? [0] Client developers have users wondering why blogging clients are so completely crippled compared to FTP and Email clients. Rename an image? Have a folder full of drafts? etc. YAGNI? [1, 2] There's been continuous feedback that feed files with link relations just aren't good enough. I tend to agree, since we've been unable to say anything meaningful about managing feed state. YAGNI? [3] It's been said that the API should be able to use static files, but none of the current protocols allow this. In fact, I don't know of any widely-used authoring protocol that does. YAGNI? [4] Two of our biggest server implementors have asked for super-basic date range queries. YAGNI? [5,6] I was asked to write an entire draft illustrating my thoughts. It's certainly not perfect or done, but it's much more capable than any other proposals we've had. The only objection I heard was something about web architecture, but no actual use case problems. And, truth be told, I could live with URI freedom, since it will cause all sorts of problems by crossing hierarchical and security boundaries, and then converge on my original suggestion. YAGNI? [7,8] We've given URIs to all sorts of things that don't have URIs in other protocols. YAGNI? There's no efficent way to incrementally update a collection with the current protocol. You see, after any protocol action, the collection representation expires, and you have to re-download the whole feed. This makes things pretty much intolerable on a cell phone. YAGNI? So, when I suggest something, I usually try to ensure that it's the simplest thing that could possibly work and Yes We Do Need It. Obviously, I could be wrong, so I'm looking for reasons why I am, or why it's not a good tradeoff. I'm not particularly interested in catchphrases or religious objections. We could do the whole thing in SOAP through one endpoint, and I would be fine with that, if it worked. If, the WG decides on a bunch of stuff I think is horrible, I will still do my best with the draft. Robert Sayre [0] http://www.imc.org/atom-protocol/mail-archive/msg00300.html [1] http://blog.kung-foo.tv/archives/001228.php [2] http://inessential.com/?comments=1postid=2988 [3] http://bitworking.org/news/Proposed_changes_to_draft_gregorio_07#X3 [4] http://www.imc.org/atom-protocol/mail-archive/msg00290.html [5] http://www.imc.org/atom-protocol/mail-archive/msg00184.html [6] http://www.imc.org/atom-protocol/mail-archive/msg00200.html [7] http://www.imc.org/atom-protocol/mail-archive/msg00384.html [8] http://www.imc.org/atom-protocol/mail-archive/msg00408.html
Re: Consensus call on last round of Paces
Tim Bray wrote: PaceExtensionConstruct One -1, 1.5 +1's. DISPOSITION: Not enough support, close it. PaceHeadless Lots of talk, more -1's than +1's. DISPOSITION: No consensus, close it. PaceLangSpecific Not a lot of discussion, but pretty positive. DISPOSITION: Borderline, but accepted. These three are tied together. Note that the second half of PaceHeadless is basically the same idea as PaceExtensionConstruct, and all of the objections to PaceHeadless centered around the name feeder and two -1s wrt to removing Atom head. Also, I count more +1s than -1s. PaceLangSpecific is pretty pointless without PaceExtensionConstruct, and so is the RDF mapping the chairs would supposedly take on as a product of this WG. PaceLinkEnclosure A little bit of support, but with reservations. DISPOSITION: A messy Pace and not enough support, close it. You're kidding, right? I can already here the chants. OMG ATOM DOESN'T DO PODCASTING LOL Robert Sayre
Re: Consensus call on last round of Paces
PaceProfile Changed along the way, quite a few +1's but even more -1's. A certain amount of +1 on concept, -1 on syntax which doesn't help. DISPOSITION: No consensus, close it. PaceProfileAttribute No significant support. DISPOSITION: Close it It would be nice if folks would actually comment in detail on these. They really have not been adequately discussed. It would be helpful if those who are -1 to the idea of profiles could offer a bit more insight into their positions. If you're +1 to the concept, but -1 to the syntax, what syntax do you think is better? If you're -1 to the concept, why? - If you just don't think it is necessary, fair enough - If you just think it's not part of the core and can be added later, fair enough, but that doesn't get around the fact that the current spec, as written, does not allow extensions to change containment requirements and therefore does not provide for a necessary aspect of profile support (the ability to change containment requirements) - If you like profiles in general, but don't like the conceptual definition in either the PaceProfile or PaceProfileAttribute proposals, what should be changed? - James M Snell Tim Bray wrote:
Re: Consensus call on last round of Paces
Tim Bray wrote: On Feb 15, 2005, at 11:52 AM, Robert Sayre wrote: PaceLinkEnclosure A little bit of support, but with reservations. DISPOSITION: A messy Pace and not enough support, close it. You're kidding, right? I can already here the chants. OMG ATOM DOESN'T DO PODCASTING LOL Uh, we already accepted PaceEnclosuresAndPix I think. This was (I believe) trying to change the name from Enclosure to Attachment. Or did we screw up? No, I screwed up. Sorry. Robert Sayre
On PaceXhtmlNamespaceDiv (was: Re: Consensus call on last round of Paces)
Tim Bray wrote: PaceXhtmlNamespaceDiv This is tough. There are some people who are really against this and who aren't moving. On the other hand, there are way more who are in favor. Reviewing the discussion, the contras are saying that this is sloppy and unnecessary and if it solves a problem, that problem really shouldn't be there, but they don't seem to be saying it's actively harmful. But the people in favor are arguing that this will reduce errors and improve interop. Also, the Pace was changed in midstream. Also, Paul thinks we will get feedback on this from out there in the IETF. DISPOSITION: Borderline, but accepted. I'm still not sure how it would improve interop, especially since the place the namespace can be defined is optional. I do not think those Planet aggregators would handle the following correct for example: atom:entry xmlns:atom=... xmlns:b=http://www.w3.org/1999/xhtml; atom:content type=XHTML b:div Foo b:br / Et cetera. ... Also, this restriction can be avoided by using |type=application/xml| or |type=application/xhtml+xml| I assume? (Although that is probably not valid for the TITLE or SUMMARY element (it should be).) -- Anne van Kesteren http://annevankesteren.nl/
attempt to comment in detail on profiling paces
James M Snell wrote: PaceProfileAttribute No significant support. DISPOSITION: Close it It would be nice if folks would actually comment in detail on these. They really have not been adequately discussed. It would be helpful if those who are -1 to the idea of profiles could offer a bit more insight into their positions. If you're +1 to the concept, but -1 to the syntax, what syntax do you think is better? If you're -1 to the concept, why? - If you just don't think it is necessary, fair enough It has yet to been explained to me why they might be necessary - so why do I need to think they're not necessary to justify an objection? ;) I've also made a (I believe significant) point in conflating @profile to @rel that hasn't been addressed (imho). The very useful thing I've seen is that @profile could be used to flag an archive. But how that's essentially different from using @rel I don't know. And I still don't understand why @version and @profile have anything to do with each other. - If you just think it's not part of the core and can be added later, fair enough, but that doesn't get around the fact that the current spec, as written, does not allow extensions to change containment requirements and therefore does not provide for a necessary aspect of profile support (the ability to change containment requirements) I don't see that as a feature as things stand, this idea that a piece of metadata can/should alter cardinality or some other aspect of the grammar. Give me a sound set of evaluation rules and what you're asking for is probably cool. Without them, no. In another thread, you mentioned that profiling is not difficult, wrt conflict resolution. I think you have to think of that difficulty with respect to things like Sam's div approach to XHTML or wf feed XML. What you're asking for here seems to hold a higher bar than what is needed for either of those - in particular it won't surprise me if conflict resolution requires programming with exceptions or heuristics in the absence of people willing to write conflict solvers. My general opinion on this type of stuff, is that if you can't determine sound evaluation rules, it has to be because the domain or the nature of the data dictates it - in this case I think vagueness on conflict resolution is an indicator that the feature being proposed is woolly. A resulting suspicion is that @profile metadata will be highly lossy in heavy aggregation and remixing scenarios, which I speculate will explode over the next 18 months. In short I'm concerned @profile is feature that will not self-interoperate. cheers Bill
Re: attempt to comment in detail on profiling paces
Bill de hÓra wrote: It has yet to been explained to me why they might be necessary - so why do I need to think they're not necessary to justify an objection? ;) Heh.. that's fair ;-) I've also made a (I believe significant) point in conflating @profile to @rel that hasn't been addressed (imho). The very useful thing I've seen is that @profile could be used to flag an archive. But how that's essentially different from using @rel I don't know. I am a firm believer in giving individual meaningful names to things. @rel works for links because it identifies how the link [EMAIL PROTECTED] to the item containing the link. How is @rel meaningful in the case of profiles? I don't believe in reusing names simply because the thing being named is somewhat similar to another thing. And I still don't understand why @version and @profile have anything to do with each other. I personally don't think @version is all that useful as it is currently defined. What use is it? What technical problem does @version satisfy? My general opinion on this type of stuff, is that if you can't determine sound evaluation rules, it has to be because the domain or the nature of the data dictates it - in this case I think vagueness on conflict resolution is an indicator that the feature being proposed is woolly. A resulting suspicion is that @profile metadata will be highly lossy in heavy aggregation and remixing scenarios, which I speculate will explode over the next 18 months. In short I'm concerned @profile is feature that will not self-interoperate. I don't see how the conflict resolution approach I suggested is vague. Profiles are evaluated independently. If multiple profiles are specified, each is validated independently of the other. Yes, this is different than what I wrote up in the PaceProfileAttribute but I've come to my senses (somewhat) since then. In any case, I definitely want to avoid getting too hyped up about this. Personally I think profiles would be a good thing, but, it does not appear that I am in the majority party on this one. So be it. - James M Snell
Re: On PaceXhtmlNamespaceDiv (was: Re: Consensus call on last round ofPaces)
[I appologize that this comes late. I was ill last week.] I'm also still not convinced about this one. It was introduced with a very good motivation, namely that it would increase the chance that namespaces would be used correctly. After the changes, what I understand is left is the following: Everybody has to use an XHTML div in every atom content of type XHTML, just to make sure that Sam (any others?) can realize his dream of atom without namespace prefixes. This despite the fact that those that want to avoid any and all namespace prefixes can use a div on their own if they want. As Sam explained, the div in that case would be part of the content. That's true, but while adding a div formally changes the content, it doesn't actually change the content, because div is just a dummy wrapper, in particular if there are no other attributes than the default namespace declaration. On more general terms, I have observed different choices of how different namespaces get put together over the last three if not more years. For the simple case of namespace B in namespace A, a variety of choices, with a variety of reasons, has been proposed. On the outer side (namespace A), the choices range from foreign namespace stuff can be inserted pretty much anywhere where it makes sense, just put it in to we have a 'foreignstuff' element, anything from another namespace has to go in there. On the inner side (namespace B), the choices again range from any B element can be used to only a wrapper element can be used. As an example, SVG tends to high explicity on both sides, for the inner side, see included document fragments (http://www.w3.org/TR/SVG11/conform#ConformingSVGIncludedDocuments), for the outer side, see foreignObject (http://www.w3.org/TR/SVG11/extend#ForeignObjectElement). Most of the motivation for this explicitness in SVG comes from the fact that without being clear on coordinates/placement/size, things won't work. Looking at these cases, it seems to me that what we are doing with div is really thinly motivated (no need for any special information such as coordinates), and is also in a way abusing div, which was created to indicate divisions in HTML documents, not to serve as a throw-away default namespace holder in foreign document formats. Actually, instead of div, we could as well define that we use body, or we could even define that we use something new like wrapper. Because as it turns out, while this element is in the XHTML namespace, it's never part of an XHTML fragment that an XHTML processor would see. At 05:05 05/02/16, Anne van Kesteren wrote: Tim Bray wrote: PaceXhtmlNamespaceDiv This is tough. There are some people who are really against this and who aren't moving. On the other hand, there are way more who are in favor. Reviewing the discussion, the contras are saying that this is sloppy and unnecessary and if it solves a problem, that problem really shouldn't be there, but they don't seem to be saying it's actively harmful. But the people in favor are arguing that this will reduce errors and improve interop. Also, the Pace was changed in midstream. Also, Paul thinks we will get feedback on this from out there in the IETF. I'm not sure I understand this sentence. Does Paul think that we will get feedback in the IETF to put it in anyway, so we better already put it in? Or that we'll get feedback to take that out in the IETF so we can as well leave it in for the moment? Or what? Regards,Martin. DISPOSITION: Borderline, but accepted. I'm still not sure how it would improve interop, especially since the place the namespace can be defined is optional. I do not think those Planet aggregators would handle the following correct for example: atom:entry xmlns:atom=... xmlns:b=http://www.w3.org/1999/xhtml; atom:content type=XHTML b:div Foo b:br / Et cetera. ... Also, this restriction can be avoided by using |type=application/xml| or |type=application/xhtml+xml| I assume? (Although that is probably not valid for the TITLE or SUMMARY element (it should be).) -- Anne van Kesteren http://annevankesteren.nl/
