Subject: New AtomPubIssuesList for 2004/09/12

From: Sam Ruby <[email-masked]>
Date: Sun, 12 Sep 2004 17:04:58 -0400

Next up: one Date proposal and Extensibility.

PaceDateSubjective is the one remaining date proposal which has attained 
the prerequisite three supporters.

The following paces deal with extensibility:

   PaceAltExtensibilityAndVersioning
   PaceExtensibilityAndVersioning
   PaceExtensionNamespace

The author of PaceDateElement has withdrawn this proposal.

- Sam Ruby

---

From: Dare Obasanjo <[email-masked]>
Date: Sun, 12 Sep 2004 16:00:30 -0700 (PDT)

Short Version: 
 PaceAltExtensibilityAndVersioning -1
 PaceExtensibilityAndVersioning    +0.5

Long Version: 

PaceExtensibilityAndVersioning 
------------------------------
PaceExtensibilityAndVersioning is about versioning yet
it doesn't talk about how it relates to version
attribute that exists on the atom:feed element. I also
don't like the fact that this Pace doesn't make a
clear delineation between extensibility and
versioning.

PaceAltExtensibilityAndVersioning 
---------------------------------
The terminology of PaceAltExtensibilityAndVersioning
is confusing in a number of places. The introduction
talks about a version element but the text seems to
reference a version attribute. I'm not really clear on
what "namespace-qualified XML attribute content"
means. Is that namespace qualified attributes or
QNames in attribute values? Then there is the quote
'The namespace prefix for the core of Atom is
described in the section titled "Notational
Conventions". That namespace is unlikely to ever
change.', I'm not sure if this is meant to be
namespace name and not namespace prefix. There are a
lot more of these haphazard uses of terminology which
made it hard to grasp the core ideas of the Pace. 

The proposed section 7.1 seems contradictory and hard
to follow specifically 

"Any future version of the Atom core that is backwards
compatible with this version will use the same version
string. An example is adding an optional element or
attribute. The only time that the version identifier
is expected to change is if elements are added to the
core Atom, if any core element has an required
attribute added, if any core element has an attribute
removed, or if the required semantics of any part of
an element in the core of Atom is changed."

So it starts of by saying that adding elements and
attributes won't change the version number then
immediately states that doing so does cause it to
change. Which is it? 

Then there's the fact that the fundamental premise
seems to be that the namespace name shouldn't change
but the version number should. I don't agree with this
approach and state as much in the section "Version
Numbers vs. Namespace Names" in the article at
http://msdn.microsoft.com/library/en-us/dnexxml/html/xml07212004.asp

THe processing model in section 7.2 states 

"- If it encounters unknown XML element content in any
namespace where the atom:must-understand flag on the
element is set to (or assumed to be) 'false', it MUST
ignore it and all it's descendents."

The "or assumed to be" is ambiguous to me since it
doesn't seem that there is an explicit statement in
this Pace that defines when it is safe to "assume"
that the atom:must-understand value is 'false' 

=====
THINGS TO DO IF I BECOME AN EVIL OVERLORD #23
I will keep a special cache of low-tech weapons and train my troops in their use. That way -- even if the heroes manage to neutralize my power generator and/or render the standard-issue energy weapons useless -- my troops will not be overrun by a handful of savages armed with spears and rocks.

_______________________________
Do you Yahoo!?
Shop for Back-to-School deals on Yahoo! Shopping.
http://shopping.yahoo.com/backtoschool

---

From: Eric Scheid <[email-masked]>
Date: Tue, 14 Sep 2004 18:59:22 +1000

> the prerequisite three supporters.

Thanks for the reminder ... I've just published PaceDateModified

http://intertwingly.net/wiki/pie/PaceDateModified

== Abstract ==

a child element of atom:entry

atom:modified is an objective machine readable date which MUST appear in
atom:entry, and contains the last datetime the entry was modified in any
way.

== Status ==

Open

== Supporters ==

 * EricScheid
 * IanDavis
 * JamesAylett
 * AsbjørnUlsberg

== Rationale ==

 * atom:updated only changes when there are "significant" changes in the
entry content, as determined by the publisher's editorial policies

 * atom:modified can be used to signal that entry content or children has
changed, without having to parse and compare all such content and children

 * atom:modified is particularly helpful for detecting changes in entry
content when all such content is located elsewhere and would require
separate retrieval (as in PaceSimpleFeedFormat) @@@ BEING DRAFTED @@@

== Proposal ==

Add a sub-section section 5 (atom:entry), near any other 'date' sections
with the following:

=== 5.x "atom:modified" Element ===

    The "atom:updated" element is a Date Construct indicating the most
    recent date and time when any change was made to the entry. Unlike
    atom:updated this would include minor adjustments like spelling and
    grammatical corrections, content reformatting, etc. It would also
    include insertion or removal of name-spaced child elements or
    extensions.

    The content of this element MUST conform to the specifications of the
    Date Construct defined in section 3.3.

    atom:entry elements MUST contain exactly one atom:modified element.
    atom:modified MUST be updated in value whenever any change in the entry
    content or children occurs. The value of atom:modified SHOULD be the
    objective current date/time of the change.

    Publishers MAY change the value of this element over time. The value of
    this element MUST be the objective date of the actual update, and not a
    subjective date related to the content.

    Publishers MAY change the value of atom:modified even if no changes in
    the entry have occurred (eg. when re-serialising or re-exporting the
    entry).

@@@ should that be "SHOULD NOT" instead of "MAY"???

== Impacts ==

 * atom:modified does not detract from atom:updated. Rather, it reinforces
it.

== Notes ==

 * atom:updated has the stated purpose of "indicating the most recent date
and time when a change was made to the entry which the publisher wishes to
bring to the attention of subscribers". atom:modified, by providing a place
for putting the modified date of an entry, reinforces that semantic, letting
it be reserved for "significant" updates.

 * atom:modified is for the benefit of software implementations such that
they can readily detect those entries which have changed, and thus trigger
re-parsing and synchronising with locally cached versions of the entry. This
is easier than re-parsing and comparing every element.

 * atom:modified may also be communicated to the end user

---

From: Sam Ruby <[email-masked]>
Date: Tue, 14 Sep 2004 11:07:37 -0400

> Thanks for the reminder ... I've just published PaceDateModified

Cool.  I'll schedule that for a later cycle.  For now, we seem to be 
making the best progress when we look at dates one at a time. 

>     The "atom:updated" element is a Date Construct indicating the most

that should be atom:modified.  I've made the change in the wiki.

>     objective current date/time of the change.

What do you mean by "content or child"?  Do you mean all child elements 
of the entry element, including content and extensions?

>     subjective date related to the content.

This last sentence makes sense to those of us who have participated in 
atom-syntax, but it hardly is a testable or enforceable requirement.  I 
think this is adequately covered by the paragraph before, so it can be 
safely dropped.

- Sam Ruby

---

From: Eric Scheid <[email-masked]>
Date: Wed, 15 Sep 2004 04:09:25 +1000

> making the best progress when we look at dates one at a time.

cool :-)

> that should be atom:modified.  I've made the change in the wiki.

oops. thanks.

> of the entry element, including content and extensions?

yes. essentially if there has been any changes to what is between <entry>
and </entry>, except of course any changes arising from xml serialisation
(including changes in the order of elements, since in atom the order of
elements are not significant).

> think this is adequately covered by the paragraph before, so it can be

ok with me. I'll edit the wiki if there are no objections.

e.

---

From: Mark Baker <[email-masked]>
Date: Wed, 15 Sep 2004 01:06:37 -0400

I'm -1 on PaceAltExtensibilityAndVersioning, and -0 on
PaceExtensibilityAndVersioning.  I do believe that the latter is a far
better starting point (i.e. minus explicit versioning), but I think the
use of mandatory extensions is too simplistic as it doesn't consider
the scope of those extensions.

Consider that the pace currently says;

'An atom compliant processor MUST process all elements marked with
mustUnderstand="true" or process none at all.'

which says to me that if there's just one entry in a feed which has a
mandatory extension that isn't understood, that the entire feed is then
not processable.  I don't believe that this behaviour is what is
desired.  So I'd propose that mandatory extensions be scoped such that
having them on a feed means the whole feed will be rejected when not
understood, but having them on an entry just means that the entry will
be.  This brings up the issue of how scopes can be extended, such as if
somebody wanted to extend Atom with a sibling to entry, but I think it
would be overkill to go there yet.

I also believe that any proposal for an extensibility mechanism that
introduces mandatory extensions needs to change the name of the media
type, at least when there's deployed code which supports the old media
type.  This is because that old code has no knowledge of the addition
of mandatory extensions and therefore will not behave properly when
confronted with them.

I'm working on PaceExtensibilityAndVersioning2, but it's getting late
and I won't finish it tonight.  I should have some time tomorrow night.

Mark.
--
Mark Baker.   Ottawa, Ontario, CANADA.        http://www.markbaker.ca

---

From: Bjoern Hoehrmann <[email-masked]>
Date: Wed, 15 Sep 2004 10:39:39 +0200

>of mandatory extensions and therefore will not behave properly when

What do you mean by media type here? Maybe you could give an example of
what you don't and do want in this regard? Do you mean that if we have
mandatory extensions in Atom, we cannot use the application/atom+xml
type any longer because there are some experimental implementations of
draft versions of the Atom formats out there? In that case, could you
explain how must-understand semantics are different from other changes
we make?

---

From: Mark Baker <[email-masked]>
Date: Wed, 15 Sep 2004 07:32:50 -0400

On Wed, Sep 15, 2004 at 10:39:39AM +0200, Bjoern Hoehrmann wrote:
> draft versions of the Atom formats out there?

Yes, exactly.

> In that case, could you

Hmm, I'm not sure how to explain it any better... perhaps an example..

I create an entry, and publish it within a feed, with the following
extension element;

  <truthValue mustUnderstand="true">untrue</truthValue>

My intent is that, because the content of the entry is untrue (perhaps
it's a joke), I only want Atom agents enabled with the "truthValue"
feature (which requires they clearly label entries as being declared to
be true or false by the author) to process it.

If I label my feed as application/atom+xml, then those early
implementations will use the old extension model to deal with the
mustUnderstand attribute; they will ignore it.  Hence, a new media type
is required as a means to inform these implementations that they can't
successfully process an entry in the feed.

Mark.

---

From: Dare Obasanjo <[email-masked]>
Date: Wed, 15 Sep 2004 05:28:55 -0700 (PDT)

--- Mark Baker <[email-masked]> wrote:

>  Do you
> mean that if we have

I appreciate the sentiment and somewhat agree with it
but I'm unclear on where we'll get the precedent for
this behavior. A big promblem with MIME types is that
often incompatible versions of a format don't change
the MIME type (e.g. are text/xml and application/xml
the MIME type of XML 1.1 documents?). 

However I am not aware of any Web technologies that
have gotten this right. This may just be my lack of
exposure to them and I'd love some examples of this
practice with some information on the issues they
encountered/resolved. 

>   <truthValue
> mustUnderstand="true">untrue</truthValue>
> 

Early implementations of what? What old extension
model? 

=====

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

---

From: Dare Obasanjo <[email-masked]>
Date: Wed, 15 Sep 2004 05:41:53 -0700 (PDT)

> explain how must-understand semantics are different

Atom isn't 1.0 yet. We should not be hamstrung by
behavior of implementations of drafts of the spec
(especially non-IETF ones). If we are going to do that
then we might as well just state that Atom 0.3 is Atom
1.0. 

=====

__________________________________
Do you Yahoo!?
Yahoo! Mail Address AutoComplete - You start. We finish.
http://promotions.yahoo.com/new_mail

---

From: Bjoern Hoehrmann <[email-masked]>
Date: Wed, 15 Sep 2004 14:51:18 +0200

* Mark Baker wrote:
>> In that case, could you explain how must-understand semantics are
>> different from other changes we make?

>successfully process an entry in the feed.

Okay, so, did you (or anyone else) test these clients whether they
currently reject e.g. documents labeled application/atom2+xml? My
impression from former discussions on MIME types is that clients
pretty much ignore the MIME type so they can successfully process
text/plain, text/html, application/octet-stream, etc. documents.
If most clients do not reject application/atom2+xml documents, we
probably need different means to solve your problem. If we agree
to solve it at all.