--On Thursday, January 13, 2005 06:55:53 PM -0500 Sam Ruby <[EMAIL PROTECTED]> wrote:
The proposal apparently is for feeds to contain other feeds by containment.
My question is whether it would make sense to also support feeds containing
other feeds by reference, perhaps via a link element or via a
On Jan 13, 2005, at 3:55 PM, Sam Ruby wrote:
I realize that the proposal isn't flushed out, but a question
nevertheless.
The proposal apparently is for feeds to contain other feeds by
containment. My question is whether it would make sense to also
support feeds containing other feeds by refere
I think that PaceUriReferences can be closed. It seems to have been
incorporated into the -04 draft as part of the "Update URI terms for
2396bis" revision.
http://www.intertwingly.net/wiki/pie/PaceUriReferences
--
Dave
On Thu, 13 Jan 2005 16:16:07 -0800, Tim Bray <[EMAIL PROTECTED]> wrote:
>
> On Jan 13, 2005, at 10:36 AM, Tim Bray wrote:
>
> > +1.
>
> The other Tim Bray, speaking as co-chair, observes that
> PaceMustUnderstandElement is hopelessly dead, with apparently no
> support and lots of detractors. T
Excellent examples. Each of these could be handled without mustUnderstand.
Define an extension for entries. Put the restricted content inside the
extension. The extension would include the display constraints between
the content portions and the disclaimer or authentication portions.
This could mea
On Jan 13, 2005, at 10:36 AM, Tim Bray wrote:
+1.
The other Tim Bray, speaking as co-chair, observes that
PaceMustUnderstandElement is hopelessly dead, with apparently no
support and lots of detractors. Thank you. You may now return to your
regularly scheduled programming. -Tim
Tim Bray wrote:
On Jan 13, 2005, at 2:29 PM, David Powell wrote:
Does anyone have any example use cases for mustUnderstand?
1. A stream of financial disclosures from a public company in a
highly-regulated industry. The legislation is very clear that they may
not say anything in public unaccompa
Roy T. Fielding wrote:
I just created a starting point for a proposal on making the
feed element recursive, eliminating the need for RDF syntax,
atom:head, and a bunch of things proposed in other paces regarding
aggregators and digital signatures.
http://www.intertwingly.net/wiki/pie/PaceFeedRecu
On Thursday, January 13, 2005, at 03:31 PM, David Powell wrote:
If there is some way to lose atom:notation without introducing
ambiguity it would be better (if something is needed, what about
atom:type as used on content - might that be a suitable replacement?)
How about: "a Structured Extension
On 13 Jan 2005, at 10:46 pm, Tim Bray wrote:
1. A stream of financial disclosures from a public company in a
highly-regulated industry. The legislation is very clear that they
may not say anything in public unaccompanied by disclaimers and
limitation-of-liability statements. The financial indu
> Are you saying that Atom 1.0 should not be extendable at all?
Paul: Not at all. I'm simply saying that "must understand" gives
influential publishers the power to force the hands of developers,
something that RSS (wisely) doesn't provide.
In addition, I have a philosophical objection, which I
On Thursday, January 13, 2005, at 03:29 PM, Roger B. wrote:
But how likely is it that the problems will
outweigh the benefits?
Antone: Extremely, in my opinion. A big -1 on this one.
All it will take is an A-lister or three on a mission to essentially
force every general-use client developer to su
On Thursday, January 13, 2005, at 03:34 PM, Graham wrote:
The main problem ince a possibly large percentage won't implement it,
using mustUnderstand in a feed doesn't prevent whatever dire
consequences there might be of ignoring the elements that must be
understood, which makes the proposed sys
Danny Ayers wrote:
fyi, Dare has blogged on "Syndicating Ordered Lists" pointing to
Netflix's rather thin RSS 2.0 feed, pointing to some holes in the
format(s). I know this scenario came up a while back somewhere around
'order', I'm not really sure how well covered it is now (or needs to
be).
OK, t
At 4:29 PM -0600 1/13/05, Roger B. wrote:
All it will take is an A-lister or three on a mission to essentially
force every general-use client developer to support whatever pet
extension they're fired up about that week, no matter how
ill-conceived.
Are you saying that Atom 1.0 should not be extenda
On Jan 13, 2005, at 2:29 PM, David Powell wrote:
Does anyone have any example use cases for mustUnderstand?
1. A stream of financial disclosures from a public company in a
highly-regulated industry. The legislation is very clear that they may
not say anything in public unaccompanied by disclaime
On 13 Jan 2005, at 9:56 pm, Antone Roundy wrote:
3. We don't need it
That's #1 above
#1 is dependent on there not being prior art. Even if there were, we
still wouldn't need it.
and it won't be implemented anywhere
Given the utter simplicity of implementation, I think it will be
implemented in m
Does anyone have any example use cases for mustUnderstand?
--
Dave
Thursday, January 13, 2005, 8:17:58 PM, you wrote:
> Danny Ayers wrote:
>> On Thu, 13 Jan 2005 08:45:07 +, David Powell <[EMAIL PROTECTED]> wrote:
>>
>> I very much like the general approach of this Pace, I reckon it's very
>> close to what's needed.
>>
>> If there is some way to lose at
> But how likely is it that the problems will
> outweigh the benefits?
Antone: Extremely, in my opinion. A big -1 on this one.
All it will take is an A-lister or three on a mission to essentially
force every general-use client developer to support whatever pet
extension they're fired up about th
On Thursday, January 13, 2005, at 01:51 PM, Graham wrote:
On 13 Jan 2005, at 6:36 pm, Tim Bray wrote:
The objections to this fall into two forms:
1. We don't have prior art in the syndication space that proves this
is needed.
2. This is someone else's problem, e.g. SOAP
3. We don't need it
That's
On 13 Jan 2005, at 6:36 pm, Tim Bray wrote:
The objections to this fall into two forms:
1. We don't have prior art in the syndication space that proves this
is needed.
2. This is someone else's problem, e.g. SOAP
3. We don't need it and it won't be implemented anywhere and it's
extremely open to
-1
I still have misgivings about the underlying model, mainly due to it's
binary nature. What happens if at some future point we want to rev the
definition of some element which has already been revved once before in it's
history? It already has the mU wart, and thus version 3 of that element
wou
Based on input received, I've moved PacePropertyDesign to the
Recommended for Closure category, and added PaceExtensionConstruct to
the Currently Under Discussion category.
- Sam Ruby
Danny Ayers wrote:
On Thu, 13 Jan 2005 08:45:07 +, David Powell <[EMAIL PROTECTED]> wrote:
I very much like the general approach of this Pace, I reckon it's very
close to what's needed.
If there is some way to lose atom:notation without introducing
ambiguity it would be better (if something is
+1.
The objections to this fall into two forms:
1. We don't have prior art in the syndication space that proves this is
needed.
2. This is someone else's problem, e.g. SOAP
I can see both those arguments, but when I re-visit and re-read this,
the implementation is so falling-off-a-log obvious, l
-0
I could live with this, but PaceMusUnderstandElement achieves 80% of
the benefit at 20% of the cost. -Tim
-1
There are as many notions of versioning in the world as there are
applications in the world, and "supersedes" model, while not that
untypical, is far from universal. It doesn't deserve to get special
treatment in Atom core. -Tim
-1
Way too complex, feels like a negative return on the complexity/benefit
trade-off. -Tim
-1
I think we can and should do without a version number. -Tim
+1
I wrote it and I still think it's necessary as a bare-minimum measure.
-Tim
-1
I think this issue has been discussed to death and the current
consensus around atom:id and atom:updated will meet users' needs simply
and elegantly. Trying to achieve consensus on a generalized abstract
model of versioning is doomed to failure. -Tim
This one shouldn't, in my opinion, be on our active-discussion queue,
because it's uncooked. That is to say, it doesn't actually propose
specific changes to our format or protocol drafts.
Having said that, the thinking seems usefully clean and minimal, and I
wouldn't be surprised if a real Pac
-0
I could live with this, but I think PaceMustUnderstandElement buys 80%
of the benefit with 20% of the cost/apparatus. -Tim
fyi, Dare has blogged on "Syndicating Ordered Lists" pointing to
Netflix's rather thin RSS 2.0 feed, pointing to some holes in the
format(s). I know this scenario came up a while back somewhere around
'order', I'm not really sure how well covered it is now (or needs to
be).
http://www.25hoursaday
Norman Walsh wrote:
I'd feel more confident about my RELAX NG grammar if I could feed
more than my own two or three test cases through it.
What we have is here:
http://intertwingly.net/wiki/pie/ConformanceTests
If anybody knows of more, please add it to the list.
- Sam Ruby
> the
> cost must be kept very near zero.
Tim: Agreed, although I'm not sure that's possible.
Right now, if someone subscribes to a feed and gets nothing, I can say
"Look, the publisher is producing ill-formed XML/invalid Atom/etc."
and leave it at that. I've got a legitimate finger to point. Bu
> I'm in favor of this--it's easy enough to imagine uses for it (like a
> feed showing the history of a particular entry).
Antone: I'm +0 about it, but it might be a good idea to include some
pointed warnings for publishers. Some client apps are going to use
the first entry in the feed, some the
This may be an obvious question and I may have missed something in
the discussion, but can someone clarify why the head:id is optional
(MAY) whereas
the entry:id is required (MUST)? Having a unique way to identify a feed
may be useful to associate a group of entries (with "heads in entries")
obtai
Tim Bray, Roy Fielding and other have recently made some interesting
comments on the atom list saying that xml's tree structure has an
implicit semantics. If this is the case then one should be able to
map any xml into triple space graph. There is no special need for
any special rdf/xml.
So let me
I'd feel more confident about my RELAX NG grammar if I could feed
more than my own two or three test cases through it.
Be seeing you,
norm
--
Norman Walsh <[EMAIL PROTECTED]> | Great success is commoner than real
h
/ Sam Ruby <[EMAIL PROTECTED]> was heard to say:
| Norman Walsh wrote:
|> 2. Why MUST a feed point to an alternate version. What if the feed is all
|>I publish?
I feel I should say that I was just asking the question, I don't have
a strong feeling one way or the other. My attention has been el
On Thu, 13 Jan 2005 08:45:07 +, David Powell <[EMAIL PROTECTED]> wrote:
I very much like the general approach of this Pace, I reckon it's very
close to what's needed.
If there is some way to lose atom:notation without introducing
ambiguity it would be better (if something is needed, what abo
On Thu, 13 Jan 2005, Martin Duerst wrote:
I don't see any clear justification in the above mail thread
for having the restriction. And I think that in a very fundamental
way, it's a mistake; feeds should be architected as independent
technology, not as an adjunct to Web pages.
I also see no reason
At 06:54 05/01/13, Sam Ruby wrote:
>
>Norman Walsh wrote:
>> 2. Why MUST a feed point to an alternate version. What if the feed is all
>>I publish?
>
>Deja vu:
>
>http://www.imc.org/atom-syntax/mail-archive/msg08836.html
>
>I'm -1 on removing this restriction.
I don't see any clear justificatio
Thursday, January 13, 2005, 1:34:24 AM, you wrote:
> On 13 Jan 2005, at 1:28 am, David Powell wrote:
>> It needs to be like this: (because namespace defaults don't apply to
>> attributes.)
>>
>> http://purl.org/atom/ns#draft-ietf-atompub-format-04";>
>> ...
>>
>> http://purl.org/atom/n
46 matches
Mail list logo
