[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: PaceDates


On Fri, 30 Jul 2004 11:34:57 +1000, Eric Scheid <eric.scheid@xxxxxxxxxxxxxxx> wrote:

That is UTC. The only difference is that the local timezone is unknown. If you think the specification text could make this clearer, please feel free to suggest what such language might look like.

my point is you've SHOULD'd against it.

Okay.

append: <<, or "-00:00" if the UTC time is known but the local time zone is unknown (eg. as a centralised hosting service might know)>>

Done. Tell me if it's appended or implemented incorrectly.

<summary is also a wildcard element - it contains arbitrary, subjective, and mutable content, and no one will know a priori whether
it will be a truncated first paragraph, a hand written summary, a
machine written summary, a bunch of keywords mushed together. 

That's different, since the content of <summary won't be parsed and
_understood_ in any way by a tool.

Nonetheless, it's a very useful thing. Ditto 'dateline' aka 'date'. It's
content, and it's valuable.


I can agree to atom:date being a 100% author-provided, subjective,
human-eye-intended date, but don't know how that can be specified to
cater for the current practice at the same time.

Who wants it, really? I know that Dare have written several times that he has never seen or heard a use case for it, but if the consensus is
that this date should be available, then okay. I think that major
changes should be signified with another mechanism than a date, though.

I want it. I asked Brent Simmons (of NNW fame) and he'd love to have it. 

Okay. I feel that this is such a far stretch after a more professional
publishing model that I don't understand why the course isn't followed
completely. If you want the perks of a professional publishing model,
why don't you just conform to one? 'Updated' is a shortcut to some of
the benefits of a professional, revisioned publishing model, but leaves
so many things «out in the blue» that it's still a hobby-publishing
model.

(I'm sorry if the word «hobby» is offending -- my intention is not to
offend anyone, it's just used to separate the two models.)

What happens when people wants another little piece of the professional
publishing model? And another piece? Should it be implemented into Atom
piece by piece, or should we instead just slam the stake in the ground
and create a really clear separation between the «hobby» and the
«professional» model?

Others can see the utility of it. People are hacking current values of
<pubDate to get the same effect today because they don't have it.


Atom doesn't have <pubDate>. If PaceDates gets consensus and is rolled
into the specification, Atom will have the equivalent 'date', which can,
but SHOULD NOT, be used for this purpose. 'modified' should. If the
changes you have made are so uninteresting that the entry is not worth
seeing again, don't change modified. If it is, change modified.

If you want a way to separate minor from major changes, apply a
professional publishing model with revisioning. Then you get version
control as a bonus.

'updated' would also be used when an entry has major changes made in
lieu of munging 'issued', which I thought was a goal of yours.


'issued' will in any case never mean 'first-issued' in a hobby
publishing model, which is why I have suggested 'first-issued' to be
used. I'm beginning to think that 'first-issued' should be withdrawn,
however, and rather have 'issued' change semantics depending on what
profile the feed conforms to.

The feed conforms to Atom Core when no profile is specified. If one or
more are specified, it conforms to them. A profile can change the
semantics of existing elements (although not so much that it makes them
backwards incompatible) and introduce new elements. Ken's suggestion on
how to apply a profile to a feed, is this:

<feed version="1.0">
  <profile xmlns="http://purl.org/atom/ns#professional-publishing"; />
  [...]
</feed>

A nice thing about this mechanism is that the 'profile' element would
reside in the non-core Atom namespace. When provided, it says that «This
feed conforms to the profile "Professional Publishing"», which e.g. will
change the semantic of atom:issued to be «The issuance of this
particular revision of a resource» and atom:id to require a  revision-
supportive URI scheme.

This is only an example, but I hope it gives you an idea of how it
might work. The point of not just applying the "Professional Publishing"
namespace to the whole Atom feed, is because everything SHOULD (or MUST)
be backwards compatible with Atom Core, and thus won't not understanding
this profile break clients (badly).

--
Asbjørn Ulsberg         -=|=-        asbjornu@xxxxxxxxxxx
«He's a loathsome offensive brute, yet I can't look away»