Sorry Tim, one more concern and I'm done.
I think mU introduces scenarios where content cannot be safely or
properly processed without looking to the metadata for control codes, ie
metadata no longer is advisory or supplementary information. I suspect
this is a significant innovation in feed
Tim Bray wrote:
+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
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. But
-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
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
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
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
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
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
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
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 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
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
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
http://www.intertwingly.net/wiki/pie/PaceMustUnderstandElement
Any Atom document MAY contain a single atom:must-understand element,
which, if it appears, MUST be the first child element of the document
element.
I think we need to add language stating that aggregators aggregating
entries
On Jan 12, 2005, at 3:25 PM, Antone Roundy wrote:
http://www.intertwingly.net/wiki/pie/PaceMustUnderstandElement
Any Atom document MAY contain a single atom:must-understand element,
which, if it appears, MUST be the first child element of the document
element.
I think we need to add language
16 matches
Mail list logo
