Subject: Re: PaceUpdatedDefinition

From: Antone Roundy <[email-masked]>
Date: Tue, 2 Nov 2004 09:53:07 -0700

On Saturday, October 30, 2004, at 11:24  AM, Robert Sayre wrote:
> Graham wrote:
>>> Graham. Who decides what constitutes a significant update?
>> For the millionth time, the publisher.
>
> OK, I don't see how the current text differs in that respect, but I'll 
> try to drive that point home, without mentioning "spelling" in a 
> normative section of the spec. How's this:
>
>  The "atom:updated" element is a Date construct indicating the most
>  recent instant in time when the [feed/entry] was modified in a way
>  the producer considers significant. Ergo, not all modifications
>  necessarily result in a changed atom:updated value.
>
-1.

I think the current draft text defines a much more useful element--one 
which can be used to signal the publisher's desires with respect to the 
modification--that people who read it before will be alerted to the 
change.  The meaning text above is very unclear to me--what criteria am 
I as a publisher supposed to use to determine whether an update is 
significant?  You're giving me no guidance at all.  As a consumer, I 
don't know whether the publisher is suggesting that I read the entry 
again, or whether they thought the change was significant but doesn't 
warrant re-reading.   For example, the publisher may have changed a lot 
of wording, reordered some paragraphs, etc., and thought "yeah, that's 
a significant change", so changed atom:updated. But if you were to ask 
them whether they'd like to have subscribers reread the entry they 
might respond "no, none of the IDEAS in the entry have changed, so 
there's no need to reread it."

Perhaps the current draft text would benefit from clarification, but I 
don't think removing the text about publisher intent is the way to go.  
The point about spelling might be moved to an example.  Including both 
significant and trivial spelling change examples, a "trivial" major 
rewriting example, and perhaps a significant minor rewrite example 
might go further in clarifying the use of this element than any 
normative text.

---

From: Robert Sayre <[email-masked]>
Date: Tue, 02 Nov 2004 12:07:26 -0500

Antone Roundy wrote:

>>
> -1.
> 
> I think the current draft text defines a much more useful element

The fact that it took you two long paragraphs to describe the 
functionality you _think_ is present in atom:updated proves that it's a 
horrbile definition.

The format has no business classifying spelling mistakes.

Robert Sayre

---

From: Bill de hÓra <[email-masked]>
Date: Tue, 02 Nov 2004 17:28:30 +0000

Antone Roundy wrote:

> significant?  You're giving me no guidance at all.  
 >
>For example, the publisher may have changed a lot 
> of wording, reordered some paragraphs, etc., and thought "yeah, that's a 
> significant change", so changed atom:updated. But if you were to ask 
> them whether they'd like to have subscribers reread the entry they might 
> respond "no, none of the IDEAS in the entry have changed, so there's no 
> need to reread it."

I think the level of discrimination in intent some people are 
looking for with these dates isn't best achieved with the Atom spec. 
I suggest leaving this to people's own writing/publishing processes 
or UI design.

My preferred text for this element is this:

[[[
The "atom:updated" element is a Date construct indicating the time 
when the [feed/entry] was changed. Not all modifications to an entry 
require a changed atom:updated value.
]]]

ie, Robert hasn't gone far enough. My strong opinion is that with 
qualifying fluff, we're imposing on users to decide about things 
they needn't be bothered about much if any of the time.

cheers
Bill

---

From: Antone Roundy <[email-masked]>
Date: Tue, 2 Nov 2004 11:03:46 -0700

On Tuesday, November 2, 2004, at 10:07  AM, Robert Sayre wrote:
> functionality you _think_ is present in atom:updated proves that it's 
> a horrbile definition.
I'll try to avoid being snippy here.  First of all, my second paragraph 
began with "Perhaps the current draft text would benefit from 
clarification"--I'm not claiming that the wording is perfect--just that 
some of the meaning that the current draft text attempts to convey 
which is absent from PaceUpdatedDefinition is useful meaning.

Second, my first paragraph contains one sentence describing the 
functionality I'd like to see atom:updated to be used for.  The rest of 
it describes what I think are the shortcomings of PaceUpdatedDefinition.

> The format has no business classifying spelling mistakes.
Sure, the spec has no business specifying normative, compulsory 
treatment of spelling adjustments with respect to atom:updated.  But 
providing examples to clarify the intended usage of an element is 
definitely in bounds.  And I think spelling adjustment examples are not 
only in bounds, but very useful.

> Original: I carved a pumkin on Halloween.
> Fixed: I carved a pumpkin on Halloween.
What subscriber on this planet is going to want to reread an entry just 
because a trivial spelling mistake like this was fixed?  Most people 
will probably have understood the entry perfectly the first time and 
won't have noticed the spelling mistake at all.

> Original: I work at a restaurant. I eat people.
> Fixed: I work at a restaurant. I seat people.
The difference between a cannibal and an usher (or whatever they're 
called in a restaurant) is pretty important.  This example is good for 
ensuring that publishers don't think that all spelling fixes are 
out-of-bounds for atom:updated.

---

From: Dare Obasanjo <[email-masked]>
Date: Tue, 2 Nov 2004 10:12:12 -0800 (PST)

> writing/publishing processes 

+1 

Folks are trying to mandate UI behavior in aggregators
via spec text which will most likely be ignored by
aggregator authors anyway. 

atom:modified is likely to be too noisy for
aggregators to actually use it as an active means of
signifiying changes to an entry. It may make sense as
a passive means of indicating changes. 

The usage of atom:updated will likely vary too widely
from feed to feed to end up providing a consistent
enough user experience for it to be used as an active
means of signifying changes to an entry. 

People who think that they can come up with the spec
text that will ensure that aggregators provide users a
consistent experience 100% of the time are fooling
themselves. 

=====
THINGS TO DO IF I BECOME AN EVIL OVERLORD #222
I reserve the right to execute any henchmen who appear to be a little too intelligent, powerful, or devious. However if I do so, I will not at some subsequent point shout "Why am I surrounded by these incompetent fools?!"

__________________________________ 
Do you Yahoo!? 
Check out the new Yahoo! Front Page. 
www.yahoo.com

---

From: Robert Sayre <[email-masked]>
Date: Tue, 02 Nov 2004 13:16:27 -0500

> only in bounds, but very useful.

I feel that you are basically making up the intended usage.

> because a trivial spelling mistake like this was fixed?  

I don't know, but "reread" isn't present in the definition.

Robert Sayre

---

From: Antone Roundy <[email-masked]>
Date: Tue, 2 Nov 2004 11:23:53 -0700

On Tuesday, November 2, 2004, at 10:28  AM, Bill de hÓra wrote:
> I think the level of discrimination in intent some people are looking 
> for with these dates isn't best achieved with the Atom spec. I suggest 
> leaving this to people's own writing/publishing processes or UI > design.
>
> qualifying fluff, we're imposing on users to decide about things they 
> needn't be bothered about much if any of the time.
>
I think atom:updated defined that way would be useless.  And I don't 
think that "the qualifying fluff" as you call it imposes an unwarranted 
decision making burden.  I think its usefulness is worth the trivial 
effort required to remember to check or uncheck a checkbox, or whatever 
trivial task would be needed to tell one's publishing software whether 
or not to change atom:updated.  As long as the default is set 
intelligently (letting the user decide what the default should be would 
be ideal), the effort required is going to be trivial.  Anyway, if 
changing atom:updated is optional, whether the basis for changing it is 
loosely defined or totally undefined, the option will have equal need 
to be presented to users.

---

From: Sam Ruby <[email-masked]>
Date: Tue, 02 Nov 2004 13:34:18 -0500

> consistent experience 100% of the time are fooling

My goal is somewhat more modest:

http://www.imc.org/atom-syntax/mail-archive/msg07673.html

- Sam Ruby

---

From: Antone Roundy <[email-masked]>
Date: Tue, 2 Nov 2004 11:34:43 -0700

On Tuesday, November 2, 2004, at 11:16  AM, Robert Sayre wrote:
>> definitely in bounds.  And I think spelling adjustment examples are 
>> not only in bounds, but very useful.
>

Okay, we obviously disagree on what we thought was the intent of the 
proposal.  When I speak of "the intended usage", I'm talking about what 
I, and I thought most of us, always considered to be the intended 
usage.  This discussion has gone on far too long for me to be able to 
state with confidence where I think the majority of us stand, but I 
still find it hard to believe that many people could have read the 
draft text significantly differently than I did.  I may be wrong.

>> What subscriber on this planet is going to want to reread an entry 
>> just because a trivial spelling mistake like this was fixed?
>

Okay, I'll rephrase: What publisher on the planet is going to want to 
alert their users to the fact that they have fixed a trivial spelling 
mistake like that?  I'm sure some will.  I, and I suspect most 
subscribers, will quickly get annoyed and unsubscribe if they make and 
flag trivial spelling mistakes often (unless our feed readers allow us 
to ignore atom:updated on those feeds).

---

From: Robert Sayre <[email-masked]>
Date: Tue, 02 Nov 2004 13:59:09 -0500

> to ignore atom:updated on those feeds).

I don't see how the Pace requires publishers to "alert their users" to a 
trivial update. Please explain.

Personally, I would prefer the text Bill proposed. I offered the Pace as 
somewhat of a compromise.

What exactly is missing from this definition? If atom:updated changes, 
the consumer knows that a "significant" update has taken place, and are 
free to act on it as they see fit. Note that this definition also 
implies that changes which take place without a change to atom:updated 
are "insignificant", whatever that means...

I don't see how we can get more specific without dictating an editorial 
policy, which is totally inappropriate.

Robert Sayre

---

From: Danny Ayers <[email-masked]>
Date: Tue, 2 Nov 2004 20:14:40 +0100

> to ignore atom:updated on those feeds).

Ok. But some people *do* intend to use atom:updated for things like
spelling changes - Robert for a start. But if I was using a CMS for
project management I'd probably want to use atom:updated to bring new
releases of existing projects to people's attention. Like you
mentioned before, this range would only work satisfactorily if the end
user sets per-feed preferences.

I get the impression that the assumption is being made that by
reducing the number of elements, the amount of work needed for
producers and consumers will be reduced. But in cases like this the
more information the publisher can supply (discriminating between
trivial and significant changes), the less work is needed at the
client. The dates may still be inaccurate and inconsistent across
feeds, but for most default behaviour should be ok, the necessary
end-user intervention will be reduced. Better for the end user.

Cheers,
Danny.

-- 

http://dannyayers.com

---

From: Dare Obasanjo <[email-masked]>
Date: Tue, 2 Nov 2004 13:34:31 -0800 (PST)

> end-user intervention will be reduced. Better for

You assume wrong. Go read
http://www.imc.org/atom-syntax/mail-archive/msg11086.html
again. 

=====

---

From: Antone Roundy <[email-masked]>
Date: Tue, 2 Nov 2004 15:57:33 -0700

On Tuesday, November 2, 2004, at 11:59  AM, Robert Sayre wrote:
>> subscribers, will quickly get annoyed and unsubscribe if they make 
>> and flag trivial spelling mistakes often (unless our feed readers 
>> allow us to ignore atom:updated on those feeds).
>
> I don't see how the Pace requires publishers to "alert their users" to 
> a trivial update. Please explain.

Sheesh.  I never said that it did.  I was responding to your assertion 
> The format has no business classifying spelling mistakes.
with examples of spelling fixes that I think clearly would and would 
not warrant altering atom:modified (with or without this Pace), and 
asserting that it is within the spec's scope to include such examples.  
Of course, if the decision of whether or not to alter atom:modified is 
up to the publisher, as I'd like it to be, some publishers will chose 
to alter it for trivial spelling fixes.  And just like they would if 
they wrote meaningless titles, those who do will degrade the quality of 
their feeds.

> Personally, I would prefer the text Bill proposed. I offered the Pace 
> as somewhat of a compromise.
>
> What exactly is missing from this definition?
The publisher's intent--to draw attention to the modification.

> If atom:updated changes, the consumer knows that a "significant" 
> update has taken place, and are free to act on it as they see fit.
Yeah, and that information would be only marginally useful as a basis 
for deciding how I as a consumer saw fit to act on it, because I have 
no idea whatsoever what the publisher meant by "significant".  I don't 
know whether I as the consumer would want to revisit the article or 
not, because the publisher would not be able to use this element to 
signal to me whether they thought the change warranted rereading or 
not.  As I mentioned in a prior message, the "significant" change could 
be the reordering of two paragraphs--certainly a "significant" change 
by some measure--but perhaps not one that alters the meaning of the 
entry in a way that warrants drawing attention to the change.

> I don't see how we can get more specific without dictating an 
> editorial policy, which is totally inappropriate.
If the current draft text were altered by removing the sentence 
mentioning spelling fixes and putting in examples along the lines I 
mention earlier ("I eat people" vs "I seat people", "pumkin" vs 
"pumpkin", along with examples showing larger changes that do and don't 
affect the meaning of the entry), and if the examples were prefaced 
with a remark about how they illustrate generally how atom:updated is 
to be used, but (as mentioned in the normative text) that the final 
decision is up to the publisher, do you think that would dictate 
editorial policy?  If so, would you explain how.  Even without taking 
extra care to indicate that the examples are illustrative guidelines 
and not normative, I don't see it doing that.

---

From: Robert Sayre <[email-masked]>
Date: Tue, 02 Nov 2004 18:27:30 -0500

Antone Roundy wrote:

> for deciding how I as a consumer saw fit to act on it, because I have no 
> idea whatsoever what the publisher meant by "significant".  

Nope. Please explain how your proposal defines a uniform definition of 
"significant" for all users of the Atom format.

> I don't know 
> whether I as the consumer would want to revisit the article or not, 
> because the publisher would not be able to use this element to signal to 
> me whether they thought the change warranted rereading or not.  As I 
> mentioned in a prior message, the "significant" change could be the 
> reordering of two paragraphs--certainly a "significant" change by some 
> measure--but perhaps not one that alters the meaning of the entry in a 
> way that warrants drawing attention to the change.
> 

Still don't get it. Whether the reordering of a paragraph is important 
is a matter of editorial policy. Some editorial policies dictate that 
every change, regardless of their effect on "meaning", are significant.

Your answer shows yet another meaning has been mapped onto atom:updated: 
that it implies the entry must be reread, which implies that everyone is 
sitting around reading emailish things. What does it mean for doing 
actual syndication?

> affect the meaning of the entry), and if the examples were prefaced with 
> a remark about how they illustrate generally how atom:updated is to be 
> used, but (as mentioned in the normative text) that the final decision 
> is up to the publisher, do you think that would dictate editorial 
> policy?  If so, would you explain how.  Even without taking extra care 
> to indicate that the examples are illustrative guidelines and not 
> normative, I don't see it doing that.
> 

I think you are describing an implementor's guide, where such text would 
  be perfectly at home.

Robert Sayre

---

From: Bill de hÓra <[email-masked]>
Date: Tue, 02 Nov 2004 23:42:04 +0000

Danny Ayers wrote:
> client. 

If there is an impasse, I believe it resides in the bracketed text 
above. I claim we can't usefully specify a distinction between 
trivial and significant - irrespective of whether we believe such a 
distinction exists or not.

I'm opposed to specifying that anyone coming into contact with Aom 
will have to think about change in terms of the format, i.e. as a 
matter of specification - they have enough to do as it is. Imagine 
for a moment a format that had "atom:trivial-change" and 
"atom:significant-change" elements.  Why trouble people with this?

cheers
Bill

---

From: Bill de hÓra <[email-masked]>
Date: Tue, 02 Nov 2004 23:42:44 +0000

> or not to change atom:updated.  

Apart from your first two claims, the rest of what you say is 
consistent with the pared down text I posted. I still don't see 
anything we need to say beyond that.

> As long as the default is set 
> loosely defined or totally undefined, the option will have equal need to 
> be presented to users.

What you've said above is much the same line of thought that leads 
me to the conclusion we need say nothing about intent or granularity 
of changes. [Nevermind that I doubt there is anything generally 
useful we can or should say here in terms of spec constraints.]

cheers
Bill

---

From: Eric Scheid <[email-masked]>
Date: Wed, 03 Nov 2004 11:27:41 +1100

> they wrote meaningless titles, those who do will degrade the quality of

you meant atom:updated, right?

e.

---

From: Eric Scheid <[email-masked]>
Date: Wed, 03 Nov 2004 11:32:06 +1100

On 3/11/04 10:42 AM, "Bill de hÓra" <[email-masked]> wrote:

> I claim we can't usefully specify a distinction between
> trivial and significant

but we can provide guidance.

just because the middle-ground is a fuzzy grey line doesn't mean that there
are not two ends to the spectrum. guidance, that's what's needed, that's
all.

e.

---

From: Antone Roundy <[email-masked]>
Date: Tue, 2 Nov 2004 18:18:04 -0700

> you meant atom:updated, right?
Oops.  Yes, I did.

---

From: [email-masked]
Date: Tue, 02 Nov 2004 20:48:53 -0500

As a consumer of information, and not a developer of Atom code, I have to 
agree wth several posts: the publisher of the information determines if 
atom:updated should have a new value, whether that publisher is human or 
machine.  The consumer of the feeds will decide what to do with 
atom:updated - some may cache everything and replace things based on the 
info being updated according to the publisher, others may always present 
things which come in the feed.  People will choose client software based on 
behaviors they like.

At 01:12 PM 11/2/04, Dare Obasanjo wrote:

>I reserve the right to execute any henchmen who appear to be a little too 
>intelligent, powerful, or devious. However if I do so, I will not at some 
>subsequent point shout "Why am I surrounded by these incompetent fools?!"
>
>
>

Tim Hare
Interested Bystander, Non-Inc.

---

From: Danny Ayers <[email-masked]>
Date: Wed, 3 Nov 2004 11:06:59 +0100

On Tue, 02 Nov 2004 23:42:04 +0000, Bill de hÓra <[email-masked]> wrote:

Imagine
> "atom:significant-change" elements. 

I'd consider that something of a side effect of a more easily framed division:

atom:updated - (human) publisher flagged change
atom:modified - publishing software flagged change (bitflips) 

> Why trouble people with this?

I think the primary reason would be so that their applications could
tell which was 'physically' the most recent version (to incorporate
spelling corrections in their archives) and which was 'editorially'
the most recent (to bring it to the end user's attention).

Specific use cases -

Choosing latest version of an individual entry from multiple sources:
http://www.imc.org/atom-syntax/mail-archive/msg10894.html

Single feed for project documentation:
http://www.imc.org/atom-syntax/mail-archive/msg10931.html

Cheers,
Danny.

-- 

http://dannyayers.com

---

From: Dare Obasanjo <[email-masked]>
Date: Wed, 3 Nov 2004 04:12:18 -0800 (PST)

I assume your goal is to enable folks like Tim Bray to
make significant updates to a blog post and then
somehow have that indicated to readers. 

This doesn't change my opinion about how useful
atom:updated or atom:modified will be in practice. I
can understand that the cost/benefit for adding one of
them may be satisfactory but definitely don't think it
is for adding both. 

Also has any blog vendor or author of a blog posting
tool actually indicated they think adding a 'indicate
this post has had significant changes in the Atom
feed' button to the UI for editing post is something
they are likely to do? From my perspective as someone
who now works on a blog service (http://spaces.msn.com
for those that don't read my blog) I doubt that we'd
want to put something like that in our UI. 

=====

---

From: Danny Ayers <[email-masked]>
Date: Wed, 3 Nov 2004 13:55:53 +0100

> want to put something like that in our UI.

From my current perspective of writing tools to demonstrate
syndication technologies, I would include such an option were it
available.

The way I would expect it to work would be that the editing tool would
include a checkbox akin to that found on Wikis on "This is a minor
edit [ ]".

Given atom:modified and atom:updated I would expect the default for
authoring software to be checked (after the initial post).

Given atom:updated alone I'm not sure what would be a reasonable default.

If the benefit of either isn't clear, we might as well just use HTML
via a polling client.

Cheers,
Danny.

-- 

http://dannyayers.com

---

From: Bill de hÓra <[email-masked]>
Date: Wed, 03 Nov 2004 13:14:33 +0000

> Given atom:updated alone I'm not sure what would be a reasonable default.

The same as if you had both.

> If the benefit of either isn't clear, we might as well just use HTML

Not the conclusion I would come to ;)

cheers
Bill

---

From: Danny Ayers <[email-masked]>
Date: Wed, 3 Nov 2004 14:17:42 +0100

PS.  Both the blogging tools I have on hand allow the modification of
the date after initial publication -

WordPress has:
"Edit timestamp?"

TypePad has:
"Publish on..."

I'd be surprised to find any moderately sophisticated content
management system that lacked such a facility.

-- 

http://dannyayers.com

---

From: "Bob Wyman" <[email-masked]>
Date: Wed, 3 Nov 2004 09:23:27 -0500

Dare Obasanjo wrote:
> From my perspective as someone who now works on a blog service 
> (http://spaces.msn.com for those that don't read my blog) I doubt
> that we'd want to put something like ['indicate this post has
> had significant changes in the Atom feed'] in our UI.
	This would seem to imply that if spaces.msn.com supports
atom:updated, it would do so as though atom:updated were defined as
atom:modified is. In other words, *any* change to an item, no matter how
small, would result in a new atom:updated value. Is this correct?

	I continue to be concerned that atom:updated seems to be an
overloading that will inevitably result in confusion. There are two bits of
information in any single instance of an atom:updated value. One is the
explicitly stated date of the update and the other is some kind of implicit
subjective and inconsistent inference hint concerning the importance of the
update. Since entry generators will not be using consistent rules for
determining "importance" and some, like spaces.msn.com won't even try to
have such rules, it is very hard to understand how a reader UI could do
anything useful with the "importance" component of atom:updated. 
	I know that I've said this before, but I think it would make much
more sense to remove the overloading by having the date of modification
specified by atom:modified and then a second optional mechanism for
explicitly stating the "importance" of the update. "Importance" could be
indicated by either an element or an attribute. i.e. one of:

	<modified>...</modified><importance>high</importance>
	Or
	<modified importance="high">...</modified>

	If "importance" is passed as explicit data, rather than implicitly,
then reader UIs can be written to handle those cases (rare or common, we
can't know yet) in which entries provide this value. There is, of course,
the issue of defining a common set of "importance" values. Defining anything
other than "low" or "high" would be, I think, an excellent task for an
extension effort. In any case, it is likely that the set of used values
would converge fairly rapidly (except for edge cases) once this feature is
let loose in the wild. 

		bob wyman

---

From: Bill de hÓra <[email-masked]>
Date: Wed, 03 Nov 2004 14:50:11 +0000

> 	<modified importance="high">...</modified>

I can see the point of doing this. However I don't think it's 
reasonable to proceed with a new set of control code attribute 
values until we establish an extension mechanism for the ones we 
already have.

cheers
Bill

---

From: Robert Sayre <[email-masked]>
Date: Wed, 03 Nov 2004 09:58:51 -0500

> anything useful with the "importance" component of atom:updated. 

Prior art in syndication suggests that this functionality is usually 
accomplished through structural changes to the entry or through new 
URIs, not timestamps. Does anyone have an example of a syndication 
format that indicates "significant updates" through a timestamp alone?

Robert Sayre

---

From: Robert Sayre <[email-masked]>
Date: Wed, 03 Nov 2004 10:04:50 -0500

Bill de hÓra wrote:
> I can see the point of doing this. 

Me too.

<modified x:priority="high">...</modified>

Robert Sayre

---

From: steve jenson <[email-masked]>
Date: Wed, 3 Nov 2004 12:12:51 -0800

> management system that lacked such a facility.

I don't think this is the same as what Dare was asking. If I understand 
those tools correctly, this will change atom:issued? Dare wants to know 
of a tool that allows you to specifically change atom:updated or 
atom:modified.

I don't know of a tool that lets you change those elements except as a 
side effect.

-steve

---

From: Eric Scheid <[email-masked]>
Date: Thu, 04 Nov 2004 12:42:20 +1100

> <modified x:priority="high">...</modified>

not a good solution though, unless you can guarantee that consumers will
receive *all* editions of the entry. If they happen to miss the entry which
has the x:priority or whatever, and a subsequent less important modification
is published, then they won't know there has been an interesting
modification at all.

that's why a timestamp of the most recent significant update is useful.

e.