Re: On PaceXhtmlNamespaceDiv (was: Re: Consensus call on last round ofPaces)

[Martin Duerst]

[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  in every atom  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  on their own if they
want. As Sam explained, the  in that case would be part
of the content. That's true, but while adding a  formally
changes the content, it doesn't actually change the content,
because  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 ''
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 
(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  is really thinly motivated (no need for any special
information such as coordinates), and is also in a way abusing
, 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 , we could as well
define that we use , or we could even define that we use
something new like . 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:
>
>  http://www.w3.org/1999/xhtml";>
>   
>
> Foo 
> 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
>  
> 

Re: attempt to comment in detail on profiling paces

[James M Snell]

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

attempt to comment in detail on profiling paces

[Bill de hÓra]

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  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: Consensus call on last round of Paces

[Anne van Kesteren]

Walter Underwood wrote:
This also means that Atom cannot be used for BBC News, where 
order is significant and non-chronological.
Could you elaborate on that?
The BBC News feeds are ordered by "importance", not date. Since the 
order is not significant, intermediate nodes could re-order the feed 
and be perfectly legal Atom processors.

A publishing date order can be recovered from the date information in
Atom. Other orders cannot.
I think that ordering by importance asks for some kind of semantic
adjustment. It should not have impact on the order in which entries appear.
--
 Anne van Kesteren
 

Re: Consensus call on last round of Paces

[Walter Underwood]

--On February 15, 2005 8:56:24 PM +0100 Anne van Kesteren <[EMAIL PROTECTED]> 
wrote:
> Walter Underwood wrote:
>> This also means that Atom cannot be used for BBC News, where order is
>> significant and non-chronological.
> 
> Could you elaborate on that?

The BBC News feeds are ordered by "importance", not date. Since the order
is not significant, intermediate nodes could re-order the feed and be
perfectly legal Atom processors.

A publishing date order can be recovered from the date information in Atom.
Other orders cannot.

wunder
--
Walter Underwood
Principal Architect, Verity

On PaceXhtmlNamespaceDiv (was: Re: Consensus call on last round of Paces)

[Anne van Kesteren]

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:

 http://www.w3.org/1999/xhtml";>
  
   
Foo 
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
 

Re: Consensus call on last round of Paces

[Robert Sayre]

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

Re: Consensus call on last round of Paces

[Tim Bray]

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?  -Tim

Re: Consensus call on last round of Paces

[Anne van Kesteren]

Walter Underwood wrote:
This also means that Atom cannot be used for BBC News, where order is
significant and non-chronological.
Could you elaborate on that?
--
 Anne van Kesteren
 

Re: Consensus call on last round of Paces

[James M Snell]

> 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

[Robert Sayre]

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

[Walter Underwood]

--On February 15, 2005 11:12:48 AM -0800 Tim Bray <[EMAIL PROTECTED]> wrote:
>
> PaceEntryOrder
> One -1, but overwhelming support otherwise.
> DISPOSITION: Accepted.

I was the -1, and there is an open issue here. Accepting this means
that Atom cannot represent RSS 1.0 feeds. Is that OK? If so, where
do we state that in the spec?

As far as I know, this is the only exception to interoperability with
other RSS formats.

This also means that Atom cannot be used for BBC News, where order
is significant and non-chronological.

wunder
--
Walter Underwood
Principal Architect, Verity

Re: Consensus call on last round of Paces

[Henry Story]

On 15 Feb 2005, at 20:12, Tim Bray wrote:
PaceRepeatIdInDocument
Lots of discussion, more -1's than +1's.
DISPOSITION: No consensus, close it.  But now we have a problem, in 
that this removed ambiguity in one direction, just closing it leaves 
the ambiguity.  So the only logical conclusion is that the WG is 
directing the editors to put language in that explicitly forbids 
entries with duplicate  in an .
Mhh. First off that pace does not speak about allowing more than one id 
per entry, but rather of allowing more than one entry with the same id 
in a feed
document.

Secondly clarifying the spec the way you are doing does not take into 
consideration the consequences of doing so. These consequences include
many other paces which have received many -1s for many reasons. But the 
main
consequence is that the spec will not be finished in time, as you will 
be opening
the debate of archive formats. Allowing this pace through, solves the 
archive
problem that is required by the Atom Charter.

I think there should be serious discussion of why this Pace is not 
thought
to be appropriate. I don't think there are ANY good arguments against 
it.

Henry Story

Consensus call on last round of Paces

[Tim Bray]

Methodology: Paul & I went through *all* the WG emails that directly 
commented on the currently open issues (see 
http://www.intertwingly.net/wiki/pie/AtomPubIssuesList); in most cases 
the calls were pretty clear.  As always, we may have mis-read the 
group, feel free to say so if you think so.

The intent is that this email serve as guidance for the editors in 
preparing the format draft that we send out for IETF last call.  We do 
not expect further material discussion of format-related Paces, it's 
now over to the whole IETF.  On the other hand, discussion of editorial 
changes is always fair game, please keep reporting what you find to the 
list, and we wouldn't be surprised if the editors turned up some corner 
cases too.

PaceAggregationDocument & PaceAggregationDocument2
One -1, nobody unambiguously in favor.
DISPOSITION: Close them.
PaceAggregationInSeparateSpec
Only a couple of voices in favor, some support conditional on profiles.
DISPOSITION: Close it, but given that the other aggregation-related 
Paces seem to be failing, it seems like a separate spec is the only 
place that this kind of work gets done.

PaceArchiveDocument
A howling mob of sharp pointy -1's.
DISPOSITION: Close it.
PaceClarifyDateUpdated
A couple of -1's, one fuzzy +1.
DISPOSITION: Close it.
PaceCollection
One pro, one contra, not much discussion.
DISPOSITION: Not enough support, close it.
PaceCommentFeeds
Two contra, one pro, some suggestion that we really need 
link/@rel="comment".
DISPOSITION: Not enough support, close it.

PaceDatesXSD
Everyone seems to like it, enough people want the regex that it's 
accepted too.
DISPOSITION: Accepted, Sayre suggested good wording calling in all the 
specs that are covered.

PaceEntriesElement
Drowning in -1's.
DISPOSITION: Close it.
PaceEntryOrder
One -1, but overwhelming support otherwise.
DISPOSITION: Accepted.
PaceExtensionConstruct
One -1, 1.5 +1's.
DISPOSITION: Not enough support, close it.
PaceFeedRecursive
Lots of -1's.
DISPOSITION: Close it.
PaceFeedState
Lots of -1's.
DISPOSITION: Close it.
PaceNoFeedState
A few +1's, nothing negative.
DISPOSITION: Accepted.
PaceFormatSecurity
Evenly split +1's and -1's.
DISPOSITION: No consensus and we have PaceSecuritySection, close it.
PaceHeadless
Lots of talk, more -1's than +1's.
DISPOSITION: No consensus, close it.
PaceIconAndImage
One -1, but broad support otherwise.
DISPOSITION: Accepted.
PaceLangSpecific
Not a lot of discussion, but pretty positive.
DISPOSITION: Borderline, but accepted.
PaceLinkEnclosure
A little bit of support, but with reservations.
DISPOSITION: A messy Pace and not enough support, close it.
PaceLinkRelVia
Moderate support, no objections.
DISPOSITION: Borderline, but accepted.
PaceMultipleImages
Lots of -1's.
DISPOSITION: Close it.
PaceMustBeWellFormed
Very little discussion, no unambiguous support.
DISPOSITION: Our longest-lived Pace is finally closed.
PaceOrderSpecAlphabetically
A bit of support, not much talk.
DISPOSITION: This is editorial, let the editors run with it.
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
PaceRemoveInfoAndHost
Not much discussion, but no opposition.
DISPOSITION: Borderline, but accepted.
PaceRemoveVersionAttribute
Quite a bit of support, quite a bit of grumbling but no loud -1's.
DISPOSITION: Borderline, but accepted.
PaceRepeatIdInDocument
Lots of discussion, more -1's than +1's.
DISPOSITION: No consensus, close it.  But now we have a problem, in 
that this removed ambiguity in one direction, just closing it leaves 
the ambiguity.  So the only logical conclusion is that the WG is 
directing the editors to put language in that explicitly forbids 
entries with duplicate  in an .

PaceSecuritySection
More support than opposition, but some feeling that the IETF is going 
to make us do something like this anyhow.
DISPOSITION: Borderline, but accepted.

PaceTextRules
Only one (positive) comment.
DISPOSITION: Not enough support, close it.
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.

===
None-Pace discussion items:
Remove Protocol stuff? See 
http://www.imc.org/atom-syntax/mail-archive/msg13431.html
Several +1's, some grumbling.
DISPOSITION: Let's do it; Paul thinks we'll get IETF feedb

Re: "atom:entry elements MUST contain an atom:summary element in any of the following cases"

[James M Snell]

For feeds intended for human consumption yes, accessibility is a 
requirement.  It should not be assumed that all feeds are intended for 
human consumption.  But, it's not worth debating right now.  +1 on 
making summary optional.

- James M Snell
Walter Underwood wrote:
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"

[Walter Underwood]

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"

[Robert Sayre]

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=1&postid=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: PaceLinkRelVia

[Robert Sayre]

+1
Robert Sayre

Re: PaceLinkRelVia

[Sam Ruby]

+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

[Fwd: draft-reschke-http-addmember-00]

[Julian Reschke]

(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:

Latest edits will be at: