Subject: PaceDateline

From: Sam Ruby <[email-masked]>
Date: Sat, 24 Jul 2004 10:38:14 -0400

http://www.intertwingly.net/wiki/pie/PaceDateline

- Sam Ruby

---

From: Asbjørn Ulsberg <[email-masked]>
Date: Sat, 24 Jul 2004 17:06:13 +0200

> http://www.intertwingly.net/wiki/pie/PaceDateline

I'm +1 on the 'dateline' element itself, but very -1 on that this element  
should replace 'modified', 'issued' and 'created'. Hence -1 on the pace.

Btw, what format should 'dateline' have? An arbitrary string?

-- 
Asbjørn Ulsberg         -=|=-        [email-masked]
«He's a loathsome offensive brute, yet I can't look away»

---

From: Sam Ruby <[email-masked]>
Date: Sat, 24 Jul 2004 11:14:17 -0400

Asbjørn Ulsberg wrote:
> I'm +1 on the 'dateline' element itself, but very -1 on that this 
> element  should replace 'modified', 'issued' and 'created'. Hence -1 on 
> the pace.
> 

Please read the entire Pace, it is not that long.

modified, issued, and created are still present, and default to the 
specified dateline.

The presumption is that dateline will be defined as a profile of ISO 8601.

- Sam Ruby

---

From: Mark Pilgrim <[email-masked]>
Date: Sat, 24 Jul 2004 11:57:45 -0400

> http://www.intertwingly.net/wiki/pie/PaceDateline

I edited the proposal to fix what appears to be a typo.  It read
"atom:dateline elements MUST contain an atom:dateline element".  I
changed this to "atom:entry elements MUST contain an atom:dateline
element".

-- 
Cheers,
-Mark

---

From: Tim Bray <[email-masked]>
Date: Sat, 24 Jul 2004 09:45:43 -0700

> http://www.intertwingly.net/wiki/pie/PaceDateline

When I first read this, I considered going over to Sam's place and 
strangling him for introducing another variable to the tangle.  But 
this has the feel of a really good idea... after all, there is a few 
centuries of prior art suggesting that it's a good idea to make it easy 
for people to time/date-stamp their stories.

BTW, the Pace is a little ambiguous, it says that atom:dateline is a 
Date construct, so where does the location go?  Is it <dateline 
when="date">location here?</dateline> or what? -Tim

---

From: Bill de hÓra <[email-masked]>
Date: Sat, 24 Jul 2004 17:48:51 +0100

> http://www.intertwingly.net/wiki/pie/PaceDateline

-1 to the co-occurence constraint below:

[[[
  Unless the following elements are also present from the dcterms 
namespace, this value is to be presumed as the the date that the 
entry was created, valid, available, issued, modified, accepted, 
copyrighted, and submitted.
]]]

cheers
Bill

---

From: Tim Bray <[email-masked]>
Date: Sat, 24 Jul 2004 10:10:24 -0700

On Jul 24, 2004, at 9:48 AM, Bill de hÓra wrote:

> namespace, this value is to be presumed as the the date that the entry 
> was created, valid, available, issued, modified, accepted, 

Explain, Bill?  Sam's saying that dateline provides the default for the 
dates from dc:terms in the case they're not provided.  I'm not getting 
your point, I think -Tim

---

From: Asbjørn Ulsberg <[email-masked]>
Date: Sat, 24 Jul 2004 19:26:20 +0200

> Please read the entire Pace, it is not that long.

I did.

> modified, issued, and created are still present, and default to the  

I can't live with an optional 'issued', sorry. :-\ I should probably have  
written that in my previous comment.

> The presumption is that dateline will be defined as a profile of ISO  

Where does the location information go, then?

---

From: Asbjørn Ulsberg <[email-masked]>
Date: Sat, 24 Jul 2004 19:26:54 +0200

On Sat, 24 Jul 2004 17:48:51 +0100, Bill de hÓra <[email-masked]> wrote:

> was created, valid, available, issued, modified, accepted, copyrighted,  
> and submitted.
> ]]]

+1 to your -1. :-)

---

From: Sam Ruby <[email-masked]>
Date: Sat, 24 Jul 2004 13:49:41 -0400

> when="date">location here?</dateline> or what? -Tim

I've updated the first line of the first note to read as follows:

     At this time, THE SYNTAX FOR providing location information has not
     been fleshed out.

- Sam Ruby

---

From: Tim Bray <[email-masked]>
Date: Sat, 24 Jul 2004 11:04:14 -0700

On Jul 24, 2004, at 10:26 AM, Asbjørn Ulsberg wrote:

> I can't live with an optional 'issued', sorry. :-\ I should probably 
> have written that in my previous comment.

Given that a substantial proportion of publications are simply not 
going to adopt your favored semantic of immutable-issued+supercede, I 
think you're going to *have* to learn to live without "issued".  I 
think you would do much better to support Sam's proposal.  If dc:issued 
is present, that would be a good signal that this publication is using 
your semantics.  If your software can't run properly without your 
"issued" semantic, then it will *never* work correctly on (for example) 
my weblog, so wouldn't you rather have that signaled? -Tim

---

From: David Powell <[email-masked]>
Date: Sat, 24 Jul 2004 19:16:33 +0100

> written that in my previous comment.

Can you explain your +2R for atom:issued a bit more? I can understand
why an aggregator of professionally published documents might require
all of those documents to have an issued date. I can also imagine that
they may be required to have some form of formal categorization field,
such as a refinement of dc:subject (I've worked on a publishing system
that did) - but nobody is suggesting that all Atom feeds should
require these other fields that are mandatory for some applications of
Atom.

So why would you require *every* Atom publication in the world to
have an issued date. Aren't these requirements just local policies of
the publishing system, rather than requirements that apply to all Atom
publications?

Another example would be a blog's comments feed. Some comments feeds
require the author to supply an email address or URL, but this can be
enforced without requiring every Atom publication in the world to
supply an email address - this is just another local policy of that
feed.

I personally don't have a problem with issued, but it seems that where
blogs supply both issued/created and modified dates, the issued dates
tend not to be used by aggregators, so I'm not convinced that all
entries should be forced to supply it unless it has a clear benefit to
the majority of readers.

-- 
Dave

---

From: Bill de hÓra <[email-masked]>
Date: Sat, 24 Jul 2004 19:21:38 +0100

> dates from dc:terms in the case they're not provided.  I'm not getting 

It's a default behaviour not worth having. I think if the dc:terms 
values are to be considered part of Atom, they should be explicitly 
present, not presumed by their absence. This Pace makes them present 
in Atom as a result of them not being there. Also, automatically 
inheriting a value from one date into another date with different 
meaning may not be desirable. It's not hard to imagine a siuation 
where a dcterms:submitted or dcterms:copyright is not written into 
an Atom entry but that the datetime value used to infer it 
downstream is not what was intended (programming through 
side-effects). The sound thing for a user to do then is to write 
these values out - so be it if they're all the same. Given the 
intense discussion around dates, it seems best that if someone wants 
to assert such terms they do so explicitly.

cheers
Bill

---

From: Dave Pawson <[email-masked]>
Date: Sat, 24 Jul 2004 19:23:35 +0100

> > http://www.intertwingly.net/wiki/pie/PaceDateline

Says, The "atom:dateline" element is a Date construct that indicates the
date and place of origin

In which case its not a semantic tag? Why 'place' in dateline?

Or is the place meant to be a child of date (yuk)

What's the process for comments?
Edit the wiki page?
(Thought I'd better ask first)
-- 
Regards DaveP.
XSLT&Docbook  FAQ
http://www.dpawson.co.uk/xsl

---

From: Eric Scheid <[email-masked]>
Date: Sun, 25 Jul 2004 04:34:23 +1000

On 25/7/04 4:04 AM, "Tim Bray" <[email-masked]> wrote:

> If dc:issued is present, that would be a good signal that this publication is
> using your semantics.

+1

Far better to have 'issued' missing than to have it polluted, and being
unable to distinguish between well behaved 'issued's and polluted 'issued's.

This is a good design pattern we should keep in mind.

e.

---

From: Sam Ruby <[email-masked]>
Date: Sat, 24 Jul 2004 14:42:40 -0400

> Says, The "atom:dateline" element is a Date construct that indicates the

The dictionary definition of the word dateline, explicitly linked from 
the PaceDateline page and repeated inside the page itself, is:

     A phrase at the beginning of a newspaper or magazine article that
     gives the date and place of its origin.

> In which case its not a semantic tag? Why 'place' in dateline?

I am not certain why that definition would make this tag non-semantic. 
Can you explain?  As to why 'place' in dateline, again it is because of 
the dictionary definition for the term.  Also from the Pace:

     If the WG decides not to provide a means for capturing the place of
     origin, then a different element name should be chosen.

> Or is the place meant to be a child of date (yuk)

 From the notes section:

     At this time, the syntax for providing location information has not
     been fleshed out.

> (Thought I'd better ask first)

 From http://www.intertwingly.net/wiki/pie/CategoryProposals :

    Discussion about proposals is to take place on the mailing list.

- Sam Ruby

---

From: Graham <[email-masked]>
Date: Sat, 24 Jul 2004 15:10:48 -0400

a) Where on earth did the dcterms idea come back from? Not discussing 
dates properly in the spec seems like a sure way to discourage 
interoperability.
b) "dateline" was offered as a name for a consensus *date* construct. 
No one said datelines themselves (ie including place information) were 
a good idea.

I really hope you're just playing devil's advocate with these two 
suggestions.

Graham

---

From: Dave Pawson <[email-masked]>
Date: Sat, 24 Jul 2004 20:21:58 +0100

>      gives the date and place of its origin.

sorry Sam, I'd missed that. I guess that's an Americanism. 
Certainly not familiar to me.

>From my interpretation, not the reference, 'tis all.

>     Discussion about proposals is to take place on the mailing list.
With recognised 'editors' amending the wiki?
Is that it?

---

From: Asbjørn Ulsberg <[email-masked]>
Date: Sat, 24 Jul 2004 21:28:00 +0200

>      At this time, THE SYNTAX FOR providing location information has not

Can't Atom use the XMLNews' <dateline>[1], as suggested by Walter  
Underwood (I think):

   <dateline>
     <location><city>Bangkok</city></location>
     <story.date>May 31, 1999</story.date>
   </dateline>

The exact syntax might need a bit tweaking, but allowing <dateline> to be  
a complexType makes it easier to express different things, at least.

____
[1] <url: http://www.xmlnews.org/docs/story-spec.html#element.dateline>

---

From: Asbjørn Ulsberg <[email-masked]>
Date: Sat, 24 Jul 2004 21:40:56 +0200

On Sat, 24 Jul 2004 19:16:33 +0100, David Powell <[email-masked]>  
wrote:

> have an issued date.

Because every Atom publication in the world is of interest to me, and the  
projects I'm involved in. You, David, are a probable content provider to  
ePerSpace, for instance. If ePerSpace is clueless regarding the context  
you wrote your entry in, that matters.

> Aren't these requirements just local policies of the publishing
> system, rather than requirements that apply to all Atom publications?

I wish it was, but; no.

> entries should be forced to supply it unless it has a clear benefit to

Just a note: RSS is new. Atom is even newer. The whole syndication space  
itself is pretty fresh.

We are specifying a format and an API that will cater for current needs  
for Atom, but they will also somewhat cater for future needs. Future needs  
for Atom will by no doubt be more advanced than the current. The simpler  
we create Atom at v 1.0, the less advanced use cases can it cater for in  
the future, because existing data will be of great importance to what  
future use cases might be.

---

From: Paul Hoffman / IMC <[email-masked]>
Date: Sat, 24 Jul 2004 12:43:14 -0700

At 7:21 PM +0100 7/24/04, Bill de hÓra wrote:
>I think if the dc:terms values are to be considered part of Atom, 
>they should be explicitly present, not presumed by their absence. 
>This Pace makes them present in Atom as a result of them not being 
>there.

How do you feel about "MUST handle atom:dateline, SHOULD handle the 
dateish dc:terms"?

--Paul Hoffman, Director
--Internet Mail Consortium

---

From: Asbjørn Ulsberg <[email-masked]>
Date: Sat, 24 Jul 2004 22:13:46 +0200

On Sat, 24 Jul 2004 19:21:38 +0100, Bill de hÓra <[email-masked]> wrote:

> present, not presumed by their absence. This Pace makes them present in  
> Atom as a result of them not being there. Also, automatically inheriting  
> a value from one date into another date with different meaning may not  
> be desirable.

+2.

> Given the intense discussion around dates, it seems best that if someone
> wants to assert such terms they do so explicitly.

Yes. I don't want to assume anything. I want to know explicitly. I agree  
that optional elements in the core isn't of much value, but that is why I  
think 'issued' should be required.

If any elements are missing, they should be assumed to be missing. Their  
values are unknown. Nothing more, nothing less. Default values is  
something I thought we were moving away from, re the optional <author>  
element discussion.

---

From: Sascha Carlin <[email-masked]>
Date: Sat, 24 Jul 2004 22:18:54 +0200

Asbjørn Ulsberg wrote:

> for Atom, but they will also somewhat cater for future needs. Future 
> needs  for Atom will by no doubt be more advanced than the current. The 
> simpler  we create Atom at v 1.0, the less advanced use cases can it 
> cater for in  the future, because existing data will be of great 
> importance to what  future use cases might be.

+10

-- 
Sascha Carlin * Heinrich-Heine-Str. 1 * 64319 Pfungstadt
http://www.itst.org/         **         +49 6157 157 205

---

From: Asbjørn Ulsberg <[email-masked]>
Date: Sat, 24 Jul 2004 22:27:07 +0200

On Sat, 24 Jul 2004 11:04:14 -0700, Tim Bray <[email-masked]> wrote:

> Given that a substantial proportion of publications are simply not going  
> to adopt your favored semantic of immutable-issued+supercede, I think  
> you're going to *have* to learn to live without "issued".

What is «a substantial proportion of publications», and who are  
responsible for them? Why is it impossible for weblogging tools to stamp  
the entries they issue with the instance in time they issue them?

I'd ask the same for 'created' and 'modified', but those aren't that  
important to me, so I won't.

> I think you would do much better to support Sam's proposal.

I'd live better with «missing 'issued' means missing issued» instead of  
'issued' having a default value equal to 'atom:dateline', but I still  
won't live good, since a formal 'issued' date is the most important date  
an entry can ever have in a publishing process.

> If dc:issued is present, that would be a good signal that this
> publication is using your semantics.

Yes, but why can't it always be present? Why is it such a difficult date  
to provide, and whenever someone wishes to provide it, they urge to modify  
it at a random pace? Why can't an immutable issued be required in the core?

> If your software can't run properly without your "issued" semantic,
> then it will *never* work correctly on (for example) my weblog

Why not? If Atom requires an 'issued' date, will you still not provide it?

---

From: Asbjørn Ulsberg <[email-masked]>
Date: Sat, 24 Jul 2004 22:36:11 +0200

On Sun, 25 Jul 2004 04:34:23 +1000, Eric Scheid  
<[email-masked]> wrote:

> Far better to have 'issued' missing than to have it polluted

I agree, but why would people pollute it? If it is managed 100% by the  
tool issuing the entries, how can it be polluted? And if tools have  
difficulties providing this date, why is that?

I understand that there will be cases where humans will b0rk something up,  
but if the most used tools implement and deploy a method that is  
compatible with my view on 'issued', those b0rked humans won't make much  
difference.

---

From: Tim Bray <[email-masked]>
Date: Sat, 24 Jul 2004 13:41:28 -0700

> Asbjørn Ulsberg wrote:
>
>> We are specifying a format and an API that will cater for current 
>> needs  for Atom, but they will also somewhat cater for future needs. 
>> Future needs  for Atom will by no doubt be more advanced than the 
>> current. The simpler  we create Atom at v 1.0, the less advanced use 
>> cases can it cater for in  the future, because existing data will be 
>> of great importance to what  future use cases might be.

Here is a list of technologies that, at the time of their arrival, were 
denounced as being "too simple": Unix, C, SQL, HTML, HTTP, XML, SMTP.  
Simple is good.  Simple gets adopted.  Simple wins.  -Tim

---

From: Tim Bray <[email-masked]>
Date: Sat, 24 Jul 2004 14:00:11 -0700

On Jul 24, 2004, at 1:27 PM, Asbjørn Ulsberg wrote:

>> think you're going to *have* to learn to live without "issued".
>
> responsible for them? Why is it impossible for weblogging tools to 
> stamp the entries they issue with the instance in time they issue 
> them?

At 'ongoing', I frequently update entries in place.  I insist on doing 
this.  It works well.  I'm not going to stop. Thus, the only two dates 
that are meaningful for an 'ongoing' entry are its advertised date 
(what we've been calling 'dateline') and its last-modified date.  Thus 
an 'issued' that didn't change would be highly misleading, and an 
'issued' that did change would be identical to 'modified'.  I don't ask 
that you adopt my publishing semantics, but I also don't expect to 
adopt yours.  I am not the only one doing this, a huge number of 
weblogs work this way.  It's one of the good things about Web 
publishing is that you can revise/correct/amplify things in place.

I have spent some years in professional publishing technology and I 
fully, completely, totally, understand your model of publishing an 
immutable article and never revising but only superseding it.  I agree 
that it's appropriate for lots of applications.  But it isn't popular 
among a large part of the user base and it isn't going to become 
popular and you are just going to have to live with this fact.

>  a formal 'issued' date is the most important date an entry can ever 
> have in a publishing process.

In *your* publishing process.  Not mine.

> Why not? If Atom requires an 'issued' date, will you still not provide 

I'd probably stay with RSS, since it doesn't try to enforce a foreign 
publishing model on me. -Tim

---

From: Eric Scheid <[email-masked]>
Date: Sun, 25 Jul 2004 07:02:25 +1000

> difficulties providing this date, why is that?

lack of capability in the tool + spec says 'issued' MUST be present
= some other date gets stuffed in there, including dates which change
= pollution

e.

---

From: Sascha Carlin <[email-masked]>
Date: Sat, 24 Jul 2004 23:32:40 +0200

> Simple is good.  Simple gets adopted.  Simple wins.  -Tim

And simple things are updated. Isn't that exactly what we are doing 
here? Taking 'simple' RSS and updateing it?

That's just the way it goes, old things are replaced by new ones. But 
some things are created with the future in mind. Think of SGML. It lives 
up until today. On the opposite, take the efforts the Germans made to 
build jets. They did not want to give up the single rear wheel and the 
whole thing blew up. Jets need to have a single (pair) front wheel and 
two (pairs) of rear wheels (actually these are under the middle of the 
jet, not at the rear, but what the heck ;) ).

This is a philisophical discussion and there are as many opionions as 
participants.

But can't we agree that creating something only by looking at the 
present is short-sighted? If one'd build a house one would build a roof 
so that it would be warm in winter and give shelter from autumn rain - 
even if the house would be build in summer, right?

---

From: Asbjørn Ulsberg <[email-masked]>
Date: Sun, 25 Jul 2004 00:04:43 +0200

> denounced as being "too simple": Unix, C, SQL, HTML, HTTP, XML, SMTP.

So since calf is meat, and meat is good, rat is also good since rat is  
meat?

---

From: Sam Ruby <[email-masked]>
Date: Sat, 24 Jul 2004 19:53:24 -0400

> With recognised 'editors' amending the wiki?

Everybody can make proposals on the wiki, as a general rule, discussion 
about proposals should occur on the mailing list.

http://www.intertwingly.net/wiki/pie/HowToGetInvolved

- Sam Ruby

---

From: Antone Roundy <[email-masked]>
Date: Sat, 24 Jul 2004 18:04:30 -0600

> On Saturday, July 24, 2004, at 02:41  PM, Tim Bray wrote:
>> Here is a list of technologies that, at the time of their arrival, 
>> were denounced as being "too simple": Unix, C, SQL, HTML, HTTP, XML, 
>> SMTP.

On Saturday, July 24, 2004, at 04:01  PM, Arve Bersvendsen wrote:
> Augh. Never press send by reflex. Addendum follows:
>
> If Unix is claimed to be 'too simple' and Unix after all is 
> 'sufficiently
> complex' does NOT in any way imply that Atom is 'sufficiently complex'
> whenever someone claims that Atom is 'too simple'

On Saturday, July 24, 2004, at 03:21  PM, Arve Bersvendsen wrote:
> Could we please at least _attempt_ to refrain from wilfully commiting
> fallacies when making our arguments?
>
> That Unix was claimed to be too simple, yet wins does not imply that 
> if Atom
> is claimed to be "too simple", Atom wins.

Sheesh people.  I hardly think Tim was arguing that "denounced as too 
simple" == "good", and "not denounced as too simple" == "bad".  The 
point is that technologies that avoid complexity that isn't required by 
most users are more likely to succeed than technologies that have the 
ability to handle everything, even though almost nobody needs it.  
Remember "80/20".  If the Atom core requires[1] support for, for 
example, a complex system for indicating which entries supercede other 
entries, which 20% (or less) of users need, then 80% (or more) of the 
target market is going to be less receptive to Atom.  They may stick 
with RSS ("it gets the job done, even if not perfectly, and I don't 
have to deal with this 'supercedes' stuff"), or they may adopt the next 
format that someone proposes to fix RSS's problems, which doesn't carry 
the burden of complexity that they don't need.

I understand that for what some of you do, "supercedes" and such are 
important.  So build an extension.  We all need to be broad minded 
enough to consider the needs of the various stakeholders, and to be 
willing to move features out of the core if they fall on the 20 side of 
80/20 and would impose a non-trivial burden on the 80.  If it turns out 
that a mojority of people DO need something that got stuck into an 
extension, fine.  Support for the extension will become a standard 
feature.

Given that using an extension in a feed isn't significantly more 
difficult than using core elements, I think that without overdoing it, 
we should aim for simplicity in the core, and not be too put out if 
some things end up in extensions.

Antone

[1] It's been said before, but I'll say it again: you can claim that 
nothing special needs to be done to support the superceding mechanism, 
but any aggregator that doesn't implement it is going to have users 
screaming about duplicate entries and jumping ship to another 
aggregator.

---

From: Paul Hoffman / IMC <[email-masked]>
Date: Sat, 24 Jul 2004 17:47:29 -0700

At 6:04 PM -0600 7/24/04, Antone Roundy wrote:
>important.  So build an extension.

+1. 'Nuff said.

--Paul Hoffman, Director

---

From: Walter Underwood <[email-masked]>
Date: Sat, 24 Jul 2004 18:46:12 -0700

>> important.  So build an extension.

I'm not sure that an extension is the right approach. PRISM already
exists (www.prismstandard.org), and has an aggregator DTD. These
issues sound like they belong in PRISM, not in Atom.

Is Atom designed to be the core of a publishing system or the edge?
If it is the edge, then it is a simplified view of the (very real)
issues internal to publishing.

wunder
--
Walter Underwood
Principal Architect, Verity

---

From: Eric Scheid <[email-masked]>
Date: Sun, 25 Jul 2004 14:50:10 +1000

On 25/7/04 10:04 AM, "Antone Roundy" <[email-masked]> wrote:

> that a majority of people DO need something that got stuck into an

+1

---

From: "Roger B." <[email-masked]>
Date: Sun, 25 Jul 2004 02:43:31 -0500

re: PaceDateline

Sam: +1

--
Roger Benningfield

---

From: Dave Pawson <[email-masked]>
Date: Sun, 25 Jul 2004 08:48:57 +0100

> How do you feel about "MUST handle atom:dateline, SHOULD handle the 

-1 to dateline.
For newsml it seems appropriate. Unless the term is more globally
acceptable I don't find it appropriate for atom, 
preferring earlier suggested options for date. 
  And does a reader really care about 'place'?
For some it may be appropriate. For many it would be totally
inappropriate. 

Should I presume that the Dublin Core definitions have been brushed
aside as insufficiently defined?

---

From: "Roger B." <[email-masked]>
Date: Sun, 25 Jul 2004 02:53:51 -0500

> A decision will need to be made as to whether or not this 
> element also replaces the feed level atom:modified element.

Sam: As has been pointed out in a few times, the feed-level atom:modified is
already extremely problematic for all but the most basic feeds. Once you get
into dynamic search feeds, things get potentially ugly on the publishing
end.

So when we get back to it, there's probably a lot to go over. (Unless the
consensus is "when in doubt, stuff now() in there," in which case forget I
said anything.)

--
Roger Benningfield
JournURL: http://journurl.com/
blog: http://admin.support.journurl.com/

---

From: David Powell <[email-masked]>
Date: Sun, 25 Jul 2004 11:11:38 +0100

Comments on various bits of PaceDateline:

> The "atom:dateline" element is a Date construct that indicates the
> date ...

+1

I'm a fan of a machine readable dateline that is a loosely associated
date for an entry.

> and place of origin for a weblog entry.

-1

I don't think that geo-data should be part of the core. It would be a
cool extension though.

I definitely don't think it should be associated with a date element,
I don't see them as being at all related. Besides, I'd rather we nail
down these date issues before we start expanding the permathread to
discussing the format and implications of geo-data.

> atom:entry elements MUST contain an atom:dateline element, but MUST
> NOT contain more than one.

+0

Making dateline mandatory is interesting, but I'm not really
convinced.

I suppose it is a date that everyone can provide, because it is just a
date associated with the entry, so it would be valid to use the value
of modified or any other date here.

> namespace

+0 to using the dublin core namespaces instead of inlining the terms
into the Atom namespace.

I'm not sure why Atom 0.3 inlines terms from dublin core into the Atom
namespace. I'm not opposed to using the terms directly from the dublin
core namespace, but this is a separate issue from which dates we chose
to include.

> Remove sections 5.6 "atom:modified", 5.7 "atom:issued", and 5.8
> "atom:created" Element.

-1

Several people thought "modified" should be required, so I'd want to
see that at least in the spec (whether it goes in atom: or dcterms: )

> this value is to be presumed as the the date that the entry was
> created, valid, available, issued, modified, accepted, copyrighted,
> and submitted.

-1

If dates aren't present, then they aren't present. I don't think that
we should require that they are defaulted to other dates. Dateline
could be in the future if it was used to associate an entry with the
date of an upcoming event, it would obviously be wrong to default most
of those dates in that case.

Atom should be communicating an author's metadata, not making it up
itself.

-- 
Dave

---

From: Asbjørn Ulsberg <[email-masked]>
Date: Sun, 25 Jul 2004 12:32:20 +0200

On Sat, 24 Jul 2004 18:04:30 -0600, Antone Roundy <[email-masked]>  
wrote:

> simple" == "good", and "not denounced as too simple" == "bad".

Probably not.

> important.  So build an extension.

Yep. I've maintained the view of having a superseding mechanism in an  
extension for a long time. I'm still maintaining that view.

> screaming about duplicate entries and jumping ship to another aggregator.

That's exactly what happens today if an entry reappears in a feed, isn't  
it? What's the difference?

And no one should be denied to switch aggregators, if another one supports  
more than the one someone's using. Supporting a supersede mechanism could  
be an edge some aggregators could have over others. Is that a bad thing?

---

From: Bill de hÓra <[email-masked]>
Date: Sun, 25 Jul 2004 12:58:42 +0100

Paul Hoffman / IMC wrote:
>> I think if the dc:terms values are to be considered part of Atom, they 
>> should be explicitly present, not presumed by their absence. This Pace 
>> makes them present in Atom as a result of them not being there.
> 
> 

Better, but here's a strawman that's stops me saying ok. Suppose 
Desperate Blog Writer (DBW) publishes an Atom entry and the dateline 
  element is part of that entry. DBW has unwittingly 
dcterms:copyrighted it whether or not a copyright was /intended/ and 
if so whether the copyright is intended on that date.

The other terms are almost certainly meaningful in the context of 
organizations that issue content and have some kind of workflow 
associated with that process (Dilbert: "I never 'acccepted' that"; 
PHB: "Our new enterprise blogging system says you did" ...). I have 
experience appying such terms to content to help determine roles and 
responsibilities for data and its alterations - this is not 
neccessarily stuff we should so easily entail. I appreciate the 
value of defaults to us technical types, but I doubt such abductive 
entailments are a good idea generally (principle of least surprise 
and all that).

cheers
Bill

---

From: Sam Ruby <[email-masked]>
Date: Sun, 25 Jul 2004 12:35:43 -0400

> see that at least in the spec (whether it goes in atom: or dcterms: )

modified is present in this proposal, and, if not present, defaults to 
the value of an element which MUST be present.  This achieves the same 
effect without requiring explicit redundancy in the common case where 
the resource has yet to be modified.

> Atom should be communicating an author's metadata, not making it up

Atom needs to be cleanly and thoroughly specified.  What this means is 
that there must be a clear and consistent way of communicating an 
author's metadata.  Such a goal is not inconsistent with the present of 
defaults.

If the author's metadata includes six dates which are known to be 
identical, one which is known to be different, and one that is unknown, 
requiring eight elements to express this is a rather cumbersome mechanism.

I added an example to the pace.

It is clear to me that in order to be inclusive, atom will have more 
dates than most people will want to have to deal with explicitly. 
Therefore, to me it makes sense for the discussion to turn to what are 
the common cases, how the syntax can be optimized for these common 
cases, and how to set expectations so that people can consistently 
interpret the resulting syntax correctly.

- Sam Ruby

---

From: Henri Sivonen <[email-masked]>
Date: Sun, 25 Jul 2004 22:06:48 +0300

> = some other date gets stuffed in there, including dates which change

That's exactly what would happen.

The main argument for allowing mode="escaped" type="text/html" on 
various elements was that GIGO-CMSs with retrofitted Atom support will 
spew out entity escaped tag soup anyway, so it is better to provide the 
means for flagging it instead of fighting the phenomenon.

I see a very different design attitude wrt. required dates. Hmm.

-- 
Henri Sivonen
[email-masked]
http://iki.fi/hsivonen/

---

From: Dare Obasanjo <[email-masked]>
Date: Sun, 25 Jul 2004 12:20:33 -0700 (PDT)

--- Asbjørn_Ulsberg <[email-masked]> wrote:
> it? 

No it isn't. I've said so at least twice on this list
already. 

=====
THINGS TO DO IF I BECOME AN EVIL OVERLORD #25
No matter how well it would perform, I will never construct any sort of machinery which is completely indestructible except for one small and virtually inaccessible vulnerable spot.

__________________________________
Do you Yahoo!?
New and Improved Yahoo! Mail - Send 10MB messages!
http://promotions.yahoo.com/new_mail

---

From: Asbjørn Ulsberg <[email-masked]>
Date: Wed, 28 Jul 2004 08:58:48 +0200

On Sat, 24 Jul 2004 14:00:11 -0700, Tim Bray <[email-masked]> wrote:

> I don't ask that you adopt my publishing semantics, but I also don't
> expect to adopt yours.

Still, «your» publishing semantics is the one that gets represented in  
Atom. I have settled with this, though. See my reply to Roger B. about  
this:

<url: http://www.imc.org/atom-syntax/mail-archive/msg07940.html>

If what I wrote there is something we can have consensus on (basically  
that all date elements are optional, but that every entry MUST have a date  
element of some sort), I'll write it up in a pace.

> among a large part of the user base and it isn't going to become popular  
> and you are just going to have to live with this fact.

Yes. Evidently.

---

From: "Laurent Le Meur" <[email-masked]>
Date: Wed, 28 Jul 2004 13:02:13 +0200

> No one said datelines themselves (ie including place information) were

Sorry but it would be a mess to use a name (Dateline) universally known in
the news industry, and *warp* its meaning in Atom = a news-related
initiative.  

A dateline appears at the beginning of a story like:
"PARIS, July 25 (AFP) - American Lance Armstrong became the first six-time
winner of the Tour de France after completing the final 20th stage of the
race into Paris here Sunday." The dateline goes up to the hyphen!

Dateline obey to strict editorial rules (you name the country only when you
send a story to people who don't know where a city is situated), identify
the location and date logically associated with the content (ie origin of
the story, a subjective notion), and are *human friendly*, so an ISO profile
is not recommended for it.

As Sam Ruby wrote in his Pace, "If the WG decides not to provide a means for
capturing the place of origin, then a different element name should be
chosen. "

ATFU NewsML 1 uses a DateLine label (human friendly), and doubles it with
what has been named "DateLineDate" (not a very elegant name I confess) which
is an ISO date. NewsML 1 also uses two other fields, FirstCreated and
ThisRevisionCreated. This could evolve in NewsML 2.

Laurent Le Meur
Agence France Presse

  > -----Message d'origine-----
  > De : [email-masked] [mailto:owner-atom-
  > [email-masked]] De la part de Graham
  > Envoyé : samedi 24 juillet 2004 21:11
  > À : Sam Ruby
  > Cc : Atom syntax
  > Objet : Re: PaceDateline - process issue
  > 
  >

---

From: Walter Underwood <[email-masked]>
Date: Thu, 29 Jul 2004 16:00:41 -0700

> The presumption is that dateline will be defined as a profile of ISO 8601.

This is completely different from Tim Bray's proposal of dateline
as a natural language string. That is also NewsML's spec for the
date portion.

-1 on the Pace.

wunder

---

From: Tim Bray <[email-masked]>
Date: Thu, 29 Jul 2004 16:23:51 -0700

> as a natural language string. That is also NewsML's spec for the

I do *not* propose that dateline should be a natural language string, 
it should be a formal date. -Tim

---

From: Walter Underwood <[email-masked]>
Date: Thu, 29 Jul 2004 16:32:11 -0700

> it should be a formal date. -Tim

Dang, I meant to double-check that before hitting send. Sorry.

Well, author-expressed dates have been dropped on the floor,
along with the LiveJournal dates. I'll post a date format thingy
in a moment.

wunder

---

From: Antone Roundy <[email-masked]>
Date: Thu, 29 Jul 2004 18:01:10 -0600

> along with the LiveJournal dates. I'll post a date format thingy
Author SELECTED dates have not been dropped--there's widespread support 
for having a Date Construct for which the author can CHOOSE an 
arbitrary date.  It's only the FORMAT of the EXPRESSION of that date 
that we seem to have strong consensus for constraining.  I presume that 
LiveJournal dates can be formatted accordingly.

---

From: Walter Underwood <[email-masked]>
Date: Thu, 29 Jul 2004 17:33:24 -0700

--On Thursday, July 29, 2004 6:01 PM -0600 Antone Roundy <[email-masked]> wrote:
> for having a Date Construct for which the author can CHOOSE an arbitrary
> date.  It's only the FORMAT of the EXPRESSION of that date that we seem
> to have strong consensus for constraining.  I presume that LiveJournal
> dates can be formatted accordingly.

In other words, author-expressions for dates have been dropped.

Formatting LiveJournal dates does not help. They are from an
unsynchronized clock (unknown time zone). Dates within a blog
can be compared, but dates from different blogs cannot be, unless
they are more than 28 hours apart.

Labeling these dates allows them to be used for ordering when
it is safe, and avoided when it is not safe.

wunder