It's my stance that it should pass through everything completely
untouched, except as required by the hub spec. (i.e. addition
of atom:source when aggregating.)
Anything short of that, in my mind, is mishandling of the content,
and I certainly wouldn't use any hub that made modifications to my
distribution. (Whitespace/etc. aside)
On 10/19/2009 3:41 PM, John Panzer wrote:
An important practical question that is going to come up
is whether a hub should pass through things it doesn't understand, in
particular, extension elements that it doesn't know anything about.
This should be explicitly mentioned in the spec IMHO, because many
libraries simply drop things on the floor that they don't grok. Or,
they just drop pieces on the floor.
I vote for pass-through of unknown elements (and attributes, but
at least all attributes on unknown elements) being at least a SHOULD.
On Mon, Oct 19, 2009 at 3:15 PM, Bob Wyman <[email protected]>
wrote:
On Mon, Oct 19, 2009 at 6:06 PM, Tim Bray <[email protected]> wrote:
> "The intent of this specification is that hub
> implementations SHOULD distribute faithful
> copies of the feeds as provided by the publishers.
bob wyman
On Mon, Oct 19, 2009 at 6:06 PM, Tim Bray <[email protected]> wrote:
On Mon, Oct 19, 2009 at 6:45 AM, Brett Slatkin < [email protected]>
wrote:
>> I think there needs to be quite a bit more clarity here. It's
clear
>> that the hub is required to preserve the atom:id. How about
the other
>> elements? I would be *very* nervous about a hub that screwed
around
>> with my atom:updated or other header fields. The current text
sounds
> My response to this would be, if you don't like how a
Hub screws with
> your content, then don't use that hub to distribute your data.
...
> Does that make sense? Is there anything that would
clarify this in the
> spec?
Yeah, it's clear that no spec can enforce ethical behaviour on the
part of of hubs. I am left troubled though by the
hint-between-the-lines flavour of the 0.2 daft, and I do think it's
important to set expectations. Let me propose some text that might
help move this discussion along:
"The intent of this specification is that hub implementations SHOULD
distribute faithful copies of the feeds as provided by the publishers.
In some cases hubs may offer to enhance feeds, for example with
statistics or translation. However, this specification cannot
guarantee the faithfulness or integrity of hub implementations.
In particular, the <atom:id> elements of feeds and their entries,
preservation of the exact value provided by the publisher is crucial
to the integrity of the whole feed ecosystem. Thus, implementations
conforming to this specification MUST reproduce the atom:id value
exactly as provided. Also, the other elements required by the Atom
specification, when provided by the publisher, MUST be present in the
version served by the hub."
I.e., in English, "We can't guarantee that hubs won't be evil or that
they'll provide bit-for-bit copies. But they really shouldn't mess
with atom:id and they shouldn't leave out required elements if you
provide them."
Based on bitter experience with implementors who have fairy-story
beliefs that specs can enforce integrity, I think that some explicit
warning is called for here. -Tim
|
