Re: New Pace: PaceAggregationInSeparateSpec

2005-02-04 Thread Robert Sayre
James Snell wrote:
That's right. Besides, HeadInEntry is trivial to do as an extension, so
there's no reason to leave it in.

I agree with this so long as there is a core mechanism that allows a
standalone entry to identify the feed to which it belongs.  That
mechanism does not have to be atom:head, but it does need to be part
of the core.
Why?
Robert Sayre


Re: New Pace: PaceAggregationInSeparateSpec

2005-02-04 Thread Henry Story
On 4 Feb 2005, at 09:05, James Snell wrote:
Bottom line: In my opinion, the parent feed is just as core to the
entries metadata as is the date it was updated or any of the other
core elements.  It *could* be defined as an extension, but I feel it
is better handled in the core.
I have heard interesting arguments It's all about the Entries, stupid!
that made the opposite assessment: namely that the entries are what is
important, and that what feed an Entry is part of, is a accident of 
life.

The idea there is that Entries are the stand alone entities. They can
be made to be part of any feed whatsoever. A feed in this 
conceptualization,
is a little like a search engine result listing where the pages they 
refer
to are like entries (notice that search engine results pages are just a
type of web page too). Which feed your entry appears in will depend very
much on the type of query the user of the search engine made.

Of course if an entry has a tag such as origin (which used to be on 
the
table) then the entry it points to would be part of the metadata of the
entry and so be a legitimate way of creating special selection of 
entries.

Henry Story


Re: PaceProfile - new

2005-02-04 Thread Bill de hÓra
James Snell wrote:
I like the fundamental idea here, but there are a couple of issues:
1. There needs to be a clear description of what a profile is.  
2. There needs to be a clear description of how profiles are defined
3. There needs to be a clear description of how profiles are handled

[...]
While this has the potential to cause a significant update to the
current document (something I'm hesitant to support), the current
@version is meaningless as is and really should be drastically
improved.  Something like the following would be far more useful.
feed profile=syndication.../feed
feed profile=archiving.../feed
feed profile=aggregation.../feed
...etc
I'm -1 on this pace.
One concern I have is that I don't want to see feed data constrained 
according to usecases (ie system monitoring); that makes the data less 
useful and goes down the route of publishers telling clients how to 
write their applications or making assumptions on how data will be 
processed downstream. While I believe that claiming Atom is a container 
for metadata is good, I doubt that profiling represents a more flexible 
approach - it moves us away from agents coordinating together to agents 
enforcing policy on one another via a profiling mechanism.

The place to put such constraints is on the range and domain of the 
metadata properties or in themed extensions - RDF clearly gets this 
right as do RSS1.0 modules. I have doubts about profiles will work out 
as they seem to range over the entire feed rather than an item of metadata.

As for @version being meaningless; it's not. It's sufficient for someone 
to swap in a code handler by switching on type. It might not have any 
forward or back compatible semantics but it is does signify wrt other 
versions. The @profile (as presented above) has no more or less meaning 
that @version.

cheers
Bill


Re: New Pace: PaceAggregationInSeparateSpec

2005-02-04 Thread Eric Scheid

On 4/2/05 6:14 PM, Robert Sayre [EMAIL PROTECTED] wrote:

 leaving things as they are
 and deferring deciding how to handle aggregation would irreversibly
 enshrine HeadInEntry into the format, which all of the current
 organizational proposals are trying to replace.
 
 That's right. Besides, HeadInEntry is trivial to do as an extension, so
 there's no reason to leave it in.

+1 to HeadInEntry being removed from the 1.0 spec.

e.



issue roundup

2005-02-04 Thread Robert Sayre
I am getting sick of arguing with you people. :)
Here is my opinion on every open issue, FWIW. I doubt any of my opinions 
will be controversial. You might disagree with one or two of them, but 
I'm guessing I predicted the WGs feelings pretty well. It's probably a 
waste of your time to argue about your pet Pace for another couple 
weeks. Listen to Paul.

---
HeadInEntry - Fine keep it. I think it's a stupid way to do one-item 
feeds, but it doesn't hurt anything, and I'm not going to explore your 
strange religion any more than I already have.

PaceExtensionConstruct - a.k.a. don't put stuff in stupid places. The 
text there is close enough to give to the editors.

PaceFormatSecurity - Could live with this if I had to, but mine is way 
better.
PaceSecuritySection - Yes, let's use this one.

PaceIconAndImage, PaceEnclosuresAndPix - Use @rel=icon, not a new 
element (we never settled any meaning for atom:link, so html convention 
wins). Use @rel=enclosure. Use an image element if you want sizes, 
otherwise use @rel=image and 1:1. Don't limit it to atom:head, haven't 
you ever read a livejournal? We already have @length, please read the 
draft before writing a Pace.

PaceMultipleImages - No. No. No.
PaceLinkRelVia - people already use it, it's cool, and straightforward. 
Yes please.

PaceCollection - overloaded term. how about trough?
PaceMustBeWellFormed - Horrible. -1. I've explained why many times, yet 
people persist in applying the term well-formed whenever someone does 
something stupid with XML.

PaceOrderSpecAlphabetically - Sure.
PaceRemoveVersionAttr - +1, people just change formats and leave the 
version number for compatibility.

PaceRemoveInfoAndHost - World Record Consensus. +1.
PaceTextRules - purports to tighten up rules, but uses only MAY and 
SHOULD. I would say undefined instead of MAY about xml:space. I wish 
we could say clients will do this instead of SHOULD. -0

PaceXhtmlNamespaceDiv - -0
PaceAggregationInSeparateSpec- How about PaceAggregationInSeparateWG?
PaceCommentFeeds - link @rel=comments. Sure, ok.
PaceFeedState, PaceNoFeedState - a good effort by mnot to set up a 
dichotomy and therefore appear to compromise when the less radical one 
is chosen. I want to reject both of them.

Archiving - Atom is perfectly good for archiving blogs. Most objections 
venture into archiving the state of a web server. Some things you might 
need if you were going to do that: A way to represent negotiated 
resources, a way to represent source and derived resources, a way to 
represent resources which act on others... all the stuff you would need 
to serialize the state of Movable Type. I just use mysqldump.

PaceAggregationDocument - Kinda scary, but also pointless.
PaceFeedRecursive - Scarier, but more useful.
PaceEntriesElement - Really rather useful, but the scariest of all.
These are so scary, Tim called them SGML/Lisp/ArchitectureAstronautics 
all at once. Note to Tim: It's faster if you just say C++. Obviously, 
these aren't going to happen. OK.

---
I think that about covers it.
Robert Sayre





Re: New Pace: PaceAggregationInSeparateSpec

2005-02-04 Thread Eric Scheid

On 4/2/05 6:48 PM, James Snell [EMAIL PROTECTED] wrote:

 I agree with this so long as there is a core mechanism that allows a
 standalone entry to identify the feed to which it belongs.  That
 mechanism does not have to be atom:head, but it does need to be part
 of the core.

link rel=feed type=application/atom+xml .../

hmmm ... it could even be:

link rel=feed type=application/atom+xml title=My Blog .../
link rel=feed type=application/atom+xml title=category foo feed.../
link rel=feed type=application/atom+xml title=my blog, with
comments.../

e.



Re: Organization Use Cases

2005-02-04 Thread Bill de hÓra
James Snell wrote:
6. Handle the problem in a non-core extension.  
I'm inclined to keep our options open on these use-cases being in or out 
of core. We don't have an extension mechanism yet other than 
atom:[EMAIL PROTECTED] Certainly Atom format work to date hasn't been framed 
as getting the evaluation of extensions right. It's might be difficult 
to add meaningful stuff later when there's no design for adding 
meaningful stuff today.

cheers
Bill


Re: PaceRemoveVersionAttr

2005-02-04 Thread Eric Scheid


I just had a thought (astounding!)

If we remove the version attribute and change the namespace only when there
is a backwards incompatible spec revision, and assume mustIgnore for
unrecognised elements from any minor version updates ... then this leaves
the door open for someone to produce feeds with any ad hoc element, even
elements which are not in any updated Atom specification.

How would a feed validator react to something like this:

  feed xmlns=http://purl.org/atom/ns#1.0;
head.../head
entry
foo.../foo
...
/entry
  /feed

It can't say foo isn't allowed in this feed, because it doesn't know if
foo was introduced in Atom 1.1. If the validator is updated to know about
Atom 1.1, the same problem exists: it doesn't know if it came from 1.2.

One of the criticisms I've seen for OPML is that anyone can add any element
or attribution of their own invention anywhere any time, and that this has
led to xml-soup.

Do we want to see the same future for Atom?

e.



Re: New Pace: PaceAggregationInSeparateSpec

2005-02-04 Thread James Snell

 I have heard interesting arguments It's all about the Entries, stupid!
 that made the opposite assessment: namely that the entries are what is
 important, and that what feed an Entry is part of, is a accident of
 life.
 
 The idea there is that Entries are the stand alone entities. They can
 be made to be part of any feed whatsoever. A feed in this
 conceptualization,
 is a little like a search engine result listing where the pages they
 refer
 to are like entries (notice that search engine results pages are just a
 type of web page too). Which feed your entry appears in will depend very
 much on the type of query the user of the search engine made.
 

OK, I can buy that, as long as that is indeed how things are supposed
to be defined.  Note, however, that the Atom syntax spec focuses on
feeds as resources and that entries just happen to be contained in
feeds. e.g. from Section 1: Atom is an XML-based document format
which describes lists of related information known as feeds.  Feeds
are composed of a number of items, known as entries, each with an
extensible set of attached metadata.  If the assertion that the
entries are the standalone entities is correct, then the text in the
spec needs to be changed to reflect that assertion.

Granting the assumption that the entries are the standalone entities
and feeds are merely just a convenient container for entries, the
identification of containing parent-feed becomes less important.  The
need to identify where the entity came from, however, obviously still
remains.. although not necessarily as a core requirement.

Back to the original point about HeadInEntry:  HeadInEntry is not
required to achieve the origin/container identification, regardless of
whether or not origin/container identification should be part of the
core.  If there are no other reasons why HeadInEntry should remain in
the core, then by all means, rip that sucker out of there. 
PaceAggregationInSeparateSpec by no means locks it in place.

 Of course if an entry has a tag such as origin (which used to be on
 the
 table) then the entry it points to would be part of the metadata of the
 entry and so be a legitimate way of creating special selection of
 entries.
 
 
 Henry Story
 
 


-- 
- James Snell
  http://www.snellspace.com
  [EMAIL PROTECTED]



Re: PaceProfile - new

2005-02-04 Thread Sam Ruby
Mark Nottingham wrote:
I tried to post this to the Wiki, but it said I wasn't allowed to. Hmm.
I have a spam throttle that limits the number of unique pages a person 
who is not logged in can edit per hour.  I'll send you login info.

- Sam Ruby


Re: On organization and abstraction

2005-02-04 Thread Roy T. Fielding
On Feb 3, 2005, at 6:37 PM, Tim Bray wrote:
On reflection, I am growing very negative on almost all of the 
Organization Paces, including FeedRecursive, PaceEntriesElement, 
PaceCollection.  Here's why: they represent to increase the level of 
abstraction in Atom, and in my experience, when the goal is 
interoperability across the network, abstraction hurts.
Hmm, I am either suffering from a bad case of ennui at the moment
or I have just completely lost track of why atom needs a syndication
format in the first place, or perhaps both.  I think your summary
reflects the email discussion, not the content of those paces.
  I would like it if the markup found in Atom documents was as close 
as possible to a typical human mental model.
... of what?  Personally, I think that is the main problem with
all of the syndication formats -- they reify an interaction model
rather than a data model.
The word feed has entered the vocabulary, even the non-geek 
vocabulary, and the notion that there are things (entries, stories, 
items, whatever) in feeds likewise.  Any attempt to abstract away 
and generalize along the lines of well, a feed is really an entry or 
well, an entry is really a feed or really, they're all just web 
resources and collections is dangerously close to verging on 
Architecture Astronautics.
Entry is a data model that easily fits the XML format, assuming
we ignore (for the moment) that entries and entry summaries are
actually quite different.  It would be nice if atom would define
a distinct data model for entry first, before it got tied up in
the details of how feeds are supposed to work.
Feed is an interaction model.  It has more to do with the pipe in
pipe-and-filter and the slash in client/server than the actual data
passed in syndication.  It carries a lot of semantic baggage, which
is fine when that is the baggage you want to define.  Other than
that, it is just data, and all data looks like an entry because
(so far) entry is completely undefined.
The purpose of PaceFeedRecursive is to simplify the feed data
format by specifying a particular method of answering the data
relationship question via XML containment.  With all due respect,
that is far more concrete a solution than what is currently in
the draft, much easier to specify, and easily implemented by
existing XML tools without the need for (or conflict with) RDF/XML.
My interest is in simplification, not abstraction.  For example,
the draft wastes a lot of text talking in the abstract about
various constructs rather than simply defining one element for
each of those constructs.  Likewise, it talks about documents
in a very abstract way, whereas it really should define entry
first (and completely) before even talking about feed documents.
It defines an element, atom:head, that serves no useful purpose
whatsoever (XML is ordered and there is nothing preventing the
syndication format from requiring that entries be provided last)
while at the same time making a mess out of atom extensibility.
Having said all that, I have no objection to withdrawing
PaceFeedRecursive and replacing it with a PaceHeadless
that simply removes atom:head.  My interest in atom is almost
all on the back-end (content management) and that is the one
piece that dirties a clean implementation via Jackrabbit
(or any CMS based on JSR 170).
I think one reason that Robert has been exploring various
alternatives is because atom is not clear on what an entry
should be, which is a separate issue that has very little
to do with the organization paces, and yet that is the one
capability that distinguishes atom from the other syndication
formats.  OTOH, if people really want just a syndication format
containing typical blog entries, then I strongly recommend
just using the proposed RSS 1.1 and move on to greener pastures.
Cheers,
Roy T. Fieldinghttp://roy.gbiv.com/
Chief Scientist, Day Software  http://www.day.com/


Re: PaceRemoveVersionAttr

2005-02-04 Thread Sam Ruby
Eric Scheid wrote:
I just had a thought (astounding!)
If we remove the version attribute and change the namespace only when there
is a backwards incompatible spec revision, and assume mustIgnore for
unrecognised elements from any minor version updates ... then this leaves
the door open for someone to produce feeds with any ad hoc element, even
elements which are not in any updated Atom specification.
How would a feed validator react to something like this:
  feed xmlns=http://purl.org/atom/ns#1.0;
head.../head
entry
foo.../foo
...
/entry
  /feed
It can't say foo isn't allowed in this feed, because it doesn't know if
foo was introduced in Atom 1.1. If the validator is updated to know about
Atom 1.1, the same problem exists: it doesn't know if it came from 1.2.
One of the criticisms I've seen for OPML is that anyone can add any element
or attribution of their own invention anywhere any time, and that this has
led to xml-soup.
Do we want to see the same future for Atom?
Whether the feedvalidator flags such an element or not, the spec 
declares (or will declare once the spec is updated to reflect the last 
round from the workgroup) such elements as invalid.

Furthermore, having things like the feedvalidator flag unknown elements 
in the Atom namespace as invalid is exactly what makes it safe for 
future authors or revisions of the Atom specification to add new 
elements in the Atom namespace without fear of conflicting with existing 
feeds.

What this does mean is that the feedvalidator either needs to be updated 
when new versions of Atom come out, or become increasingly irrelevant 
and obsolete as new validators assume this role (possibly something as 
simple as a RelaxNG schema).

- Sam Ruby


Re: PaceProfile - new

2005-02-04 Thread Mark Nottingham
Bill,
I'm sorry, I don't think I get what you're saying; the words all make 
sense, but I don't know how you got here.

Atom currently constrains feed data (e.g., you MUST have a title, there 
MUST only be one) based on the most common use case; bloggling/news 
syndication. How does this move towards agents enforcing policy on one 
another? If anything, the Pace makes it *less* likely that publishers 
will make assumptions about how data will be processed downstream; as 
Atom is currently specified, there are lots of such assumptions built 
in.

The Pace doesn't place any requirements on Atom Processors WRT 
@profile; it's just an advisory flag that tells it what kinds of 
metadata it can count on appearing in the feed.

On Feb 4, 2005, at 1:53 AM, Bill de hÓra wrote:
One concern I have is that I don't want to see feed data constrained 
according to usecases (ie system monitoring); that makes the data less 
useful and goes down the route of publishers telling clients how to 
write their applications or making assumptions on how data will be 
processed downstream. While I believe that claiming Atom is a 
container for metadata is good, I doubt that profiling represents a 
more flexible approach - it moves us away from agents coordinating 
together to agents enforcing policy on one another via a profiling 
mechanism.
--
Mark Nottingham http://www.mnot.net/



PaceAggregationDocument2 posted

2005-02-04 Thread Antone Roundy
http://www.intertwingly.net/wiki/pie/PaceAggregationDocument2
Simplified version of PaceAggregationDocument: adds an aggregation 
document element without attempting to redefine all Atom elements as 
either metadata or containers in order to make the impact on the 
current specification easier to gauge.



Re: Don't mess with HeadInEntry!

2005-02-04 Thread Antone Roundy
On Friday, February 4, 2005, at 01:29  AM, Bob Wyman wrote:
	4. We've been talking about HeadInEntry ever since I proposed it
back in June at the Atom Community meeting. On numerous occasions, the 
group
as a whole has rejected the various feed of feed proposals as overly
complex and unnecessary. It is a bit bizarre to see all this being 
rehashed
in a rush as we drive towards a Last Call.
It seems to me that the main reason for the objections to feed of 
feeds was that it seemed to open the way to unlimited recursion.  I 
too am a little surprised to see proposals for recursive feeds of 
feeds--that's what sparked the idea of the Aggregation Document you've 
taken such a disliking to.

	6. All of the alternatives that have been proposed require drastic
and unlikely modifications to the design and architecture of readers. 
(i.e.
stuff like adding an aggregation document!!) Such proposals are not 
viable
alternatives no matter how sweet one might find their abstractions...
I suspect that the large volume of proposed text that 
PaceAggregationDocument lifted from PaceFeedRecursive made it look a 
lot more drastic than it really is.  In both of those proposals, the 
proposed text was largely identical to what's in the current 
draft--it's just been moved around and one or two little changes made.  
However, there is a point to the argument that we should minimize how 
much mucking around with do with things right now, so I've posted 
PaceAggregationDocument2, which only proposes the changes necessary to 
create an Aggregation Document.

As for HeadInEntry, the best argument I see for it if we adopt a 
containment-based aggregation mechanism is that Entry Documents may 
need to be able to refer to their feeds for context.  I can think of 
three ways to handle that:

1) A link to their feed
2) Use a one-entry Feed Document instead of an Entry Document
3) Allow HeadInEntry in Entry Documents only


Re: PaceRemoveInfoAndHost

2005-02-04 Thread Norman Walsh
/ Mark Nottingham [EMAIL PROTECTED] was heard to say:
| +1
|
| Welcome to the club :)

+1. I'll join. :-)

Be seeing you,
  norm

-- 
Norman Walsh [EMAIL PROTECTED] | A man may by custom fortify himself
http://nwalsh.com/| against pain, shame, and suchlike
  | accidents; but as to death, we can
  | experience it but once, and are all
  | apprentices when we come to it.--
  | Montaigne


pgp9LBpWPG48b.pgp
Description: PGP signature


xsd:dateTime vs. RFC 3339

2005-02-04 Thread Norman Walsh
The 05 draft of the Atom format says:

  3.3  Date Constructs

  A Date construct is an element whose content MUST conform to the
  date-time BNF rule in [RFC3339].

I'm actually using xsd:dateTime in the RELAX NG grammar and I went off
to look at RFC 3339 thinking I might write a regex to do that instead,
since that's what the spec says. Then I got to wondering just how similar
the two definitions actually are. In some private correspondence, Paul
Byron made the following observations:

1. RFC 3339 allows lower- and upper-case 'T' and 'Z', while
   xsd:dateTime requires upper-case only. There is a note in sect 5.6
   of RFC 3339 which says:

  This date/time format may be used in some environments or
  contexts that distinguish between the upper- and lower-case
  letters 'A'-'Z' and 'a'-'z' (e.g. XML). Specifications that use
  this format in such environments MAY further limit the date/time
  syntax so that the letters 'T' and 'Z' used in the date/time
  syntax must always be upper case. Applications that generate
  this format SHOULD use upper case letters.

2. RFC 3339 allows the replacement of the 'T' with a space which
   xsd:dateTime does not. [Note: ISO 8601 doesn't either, hence RFC
   3339 isn't actually a profile of ISO 8601 as it claims].

3. RFC 3339 does not allow the hour 24 but xsd:dateTime does (in
   xsd:dateTime [as in ISO 8601] 00  24 both represent midnight, but
   24 means the end of one day while 00 means the start of the next)

4. RFC 3339 gives a different semantic to a timezone offset of -00:00 from
   +00:00 and Z which xsd:dateTime (and to the best of my knowledge
   ISO 8601) doesn't. Sect 4.3 of RFC 3339 reads:

 If the time in UTC is known, but the offset to local time is
 unknown, this can be represented with an offset of -00:00. This
 differs semantically from an offset of Z or +00:00, which
 imply that UTC is the preferred reference point for the specified
 time. RFC2822 [IMAIL-UPDATE] describes a similar convention for
 email.

He goes on to suggest that there may be other differences, but these
are the ones he noticed. That's enough for me: they are different.

I know we're writing an IETF document, but I think there's going to be
a lot of off-the-shelf XML software that understands xsd:dateTimes and
I think it would be a lot better if we defined Date Constructs in
terms of W3C XML Schema Part 2 than RFC 3339.

I propose that we change the spec to do so.

Be seeing you,
  norm

-- 
Norman Walsh [EMAIL PROTECTED] | It is important what a man still plans
http://nwalsh.com/| at the end. It shows the measure of
  | injustice in his death.--Elias Canetti


pgpaoXTihvMZ6.pgp
Description: PGP signature


Re: PaceProfile - new

2005-02-04 Thread Bill de hÓra
Mark Nottingham wrote:
Bill,
I'm sorry, I don't think I get what you're saying; the words all make 
sense, but I don't know how you got here.

[../]
The Pace doesn't place any requirements on Atom Processors WRT @profile; 
it's just an advisory flag that tells it what kinds of metadata it can 
count on appearing in the feed.
Ok, I'll calm down and try again.
If the advisory @profile scopes at the level of the feed, I think that's 
too broad a scope. It needs to scope at the level of the entry, or it's 
liable to becomes meaningless when entries are mixed and matched. I can 
barely figure out how to class individual entries, never mind entire 
feeds. Maybe there's a use case I'm not getting.

cheers
Bill



Re: PaceIconAndImage

2005-02-04 Thread Antone Roundy
On Thursday, January 27, 2005, at 09:08  AM, Antone Roundy wrote:
Also, why limit this to feed/head, and not entry?
If we ARE going to limit images to feeds, then please, let's change the 
name to logo.  If it were logo, I'd agree it doesn't belong in 
entry.



Re: xsd:dateTime vs. RFC 3339

2005-02-04 Thread Robert Sayre
Norman Walsh wrote:
The 05 draft of the Atom format says:
I know we're writing an IETF document, but I think there's going to be
a lot of off-the-shelf XML software that understands xsd:dateTimes and
I think it would be a lot better if we defined Date Constructs in
terms of W3C XML Schema Part 2 than RFC 3339.
I propose that we change the spec to do so.
I agree. I was just writing a protocol implementation in Ruby On Rails 
(CRUDs very fast, btw). When I got to the part on date formats, I used 
xsd:dateTime code that was already done, figuring that's what everyone 
else will do.

Robert Sayre


Re: xsd:dateTime vs. RFC 3339

2005-02-04 Thread Julian Reschke
Robert Sayre wrote:
Norman Walsh wrote:
The 05 draft of the Atom format says:
I know we're writing an IETF document, but I think there's going to be
a lot of off-the-shelf XML software that understands xsd:dateTimes and
I think it would be a lot better if we defined Date Constructs in
terms of W3C XML Schema Part 2 than RFC 3339.
I propose that we change the spec to do so.
I agree. I was just writing a protocol implementation in Ruby On Rails 
(CRUDs very fast, btw). When I got to the part on date formats, I used 
xsd:dateTime code that was already done, figuring that's what everyone 
else will do.
But in that case, we'll need to profile xsd:dateTime. For instance, that 
one allows timestamps without timezone (with a distinct meaning!).

Best regards, Julian
--
green/bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760


Re: xsd:dateTime vs. RFC 3339

2005-02-04 Thread Norman Walsh
/ Julian Reschke [EMAIL PROTECTED] was heard to say:
| Robert Sayre wrote:
[...]
| I agree. I was just writing a protocol implementation in Ruby On
| Rails (CRUDs very fast, btw). When I got to the part on date
| formats, I used xsd:dateTime code that was already done, figuring
| that's what everyone else will do.
|
| But in that case, we'll need to profile xsd:dateTime. For instance,
| that one allows timestamps without timezone (with a distinct meaning!).

Or not. I propose that we say that Date Constructs MUST be valid
xsd:dateTime values and SHOULD include an explicit time zone. Heck, I
could even live with SHOULD be in UTC. If pressed, I could live with
MUST be in UTC.

But the evidence suggests that software is, in practice, going to use
libraries that recognize and process xsd:dateTime values, so defining
it in some other way is just going to lead to deviation from the spec.

Be seeing you,
  norm

-- 
Norman Walsh [EMAIL PROTECTED] | He that shuns trifles must shun the
http://nwalsh.com/| world.--George Chapman


pgpBbAcxtTLeo.pgp
Description: PGP signature


Re: xsd:dateTime vs. RFC 3339

2005-02-04 Thread Norman Walsh
/ Julian Reschke [EMAIL PROTECTED] was heard to say:
[...]
| So what do you do with something like
|
|   2005-02-04T17:20:00

Dunno.

| - Neither xsd:dateTime nor RFC3339 are perfect for our needs, so we
| may have to profile one of them. In which case I'd prefer to stick
| with RFC3339.

*shrug* I've said why I think xsd:dateTime is a better choice, but
you're right, we just have to pick one.

Be seeing you,
  norm

-- 
Norman Walsh [EMAIL PROTECTED] | A new scientific truth does not triumph
http://nwalsh.com/| by convincing its opponents and making
  | them see the light, but rather because
  | its opponents eventually die, and a new
  | generation grows up that is familiar
  | with it (Planck 1949)


pgp6pYXNu9b9k.pgp
Description: PGP signature


Re: xsd:dateTime vs. RFC 3339

2005-02-04 Thread Norman Walsh
/ Julian Reschke [EMAIL PROTECTED] was heard to say:
| - Neither xsd:dateTime nor RFC3339 are perfect for our needs, so we
| may have to profile one of them. In which case I'd prefer to stick
| with RFC3339.

Perhaps a compromise? Date Construct values MUST be valid xsd:dateTime
values and MUST also match the following regular expression:

  [0-9]{8}T[0-9]{2}:[0-9]{2}:[0-9]{2}(\.[0-9]+)?(Z|[\+\-][0-9]{2}:[0-9]{2})

(Expressed for my own testing purposes in XML Schema pattern syntax.)

Be seeing you,
  norm

-- 
Norman Walsh [EMAIL PROTECTED] | Some disguised deceits counterfeit
http://nwalsh.com/| truth so perfectly that not to be taken
  | in by them would be an error of
  | judgment.--La Rochefoucauld


pgp2sukhn4EYA.pgp
Description: PGP signature


Re: xsd:dateTime vs. RFC 3339

2005-02-04 Thread Julian Reschke
Walter Underwood wrote:
--On February 4, 2005 11:18:17 AM -0500 Norman Walsh [EMAIL PROTECTED] wrote:
I know we're writing an IETF document, but I think there's going to be
a lot of off-the-shelf XML software that understands xsd:dateTimes and
I think it would be a lot better if we defined Date Constructs in
terms of W3C XML Schema Part 2 than RFC 3339.

Strongly agree.
Also, we have an unresolved issue with historic Livejournal entries,
which do not have timezones. XML Schema explains exactly how to 
So what does it recommend?
handle those. We can have a SHOULD for timezone info, with an explanation
of what you lose without that.
So what is a recipient of a timestampe without TZ info supposed to do 
with it? Throw it away? Default to UTC?

-1
--
green/bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760


Re: On organization and abstraction

2005-02-04 Thread Tim Bray
On Feb 4, 2005, at 9:10 AM, Robert Sayre wrote:
My interest is in simplification, not abstraction.  For example,
the draft wastes a lot of text talking in the abstract about
various constructs rather than simply defining one element for
each of those constructs.
Person, Date, and Text constructs all save space because they avoid 
repetitive requirements, and they match up nicely with the Relax NG. 
I'm pretty sure the group has agreed to drop Service constructs, and 
mnot has already moved atom:id into an element definition for -06.
Right, and Brent Simmons, one of the major implementors, published a 
blog entry talking about how much, as a programmer, he liked the 
person and link and so on constructs.  -Tim



Pace production and process

2005-02-04 Thread Tim Bray
To those of you who have been providing Paces before the deadline, our 
thanks.  This is a reminder that sometime on Monday, Sam is going to do 
the *last* rev of AtomPubIssuesList before IETF last call.  Both Paul 
and I have 100% confidence in Sam's judgement as to which Paces are 
well-enough cooked to merit inclusion in the Currently Under 
Discussion list.

We're also happy to see some structure building up around the 
extension-proposal process.

It would be really nice for us co-chairs if we could make our consensus 
call based mostly on what happens next week; I think the debate this 
week has been really useful, but both the Paces and the individual 
opinions have been shifting so much that I despair of pulling anything 
useful consensus-wise out of it.  So I'd encourage everyone, once Sam 
fires the starting gun, to get in there with their +1's and -1's so we 
know where everyone ended up.

And (process note) I will be in Maui from Sunday to Sunday and (hard to 
believe I know) not thinking very much about syndication technology.  
So Paul gets to watch the flow by himself.  In practical terms, this 
means it may take us till sometime around the 15th or so to do that 
last consensus call.  -Tim



RE: Entry order

2005-02-04 Thread Walter Underwood

--On February 3, 2005 11:21:50 PM -0500 Bob Wyman [EMAIL PROTECTED] wrote:
 David Powell wrote:
 It looks like this might have got lost accidently when the 
 atom:head element was introduced. Previously Atom 0.3 said [1]:
 Ordering of the element children of atom:feed element MUST NOT be
 considered significant.
   +1. 
   The order of entries in an Atom feed should NOT be significant. This
 is, I think, a very, very important point to make. 

-1

Is this a joke? This is like saying that the order of the entries in my
mailbox is not significant. Note that ordering a mailbox by date is not
the same thing as its native order. 

Feed order is the only way we have to show the publication order of items 
in a feed. I just looked at all my subscriptions, and there is only one
where the order might not be relevant, a security test for RSS readers.
That is clearly not within Atom's charter, so it doesn't count.

wunder
--
Walter Underwood
Principal Architect, Verity



Re: PaceIconAndImage

2005-02-04 Thread Robert Sayre
Antone Roundy wrote:
Let me restate this in a way that might lead to action: I have a 
sneaking suspicion that we're not going to get consensus on allowing 
image and/or icon in entry.  If that's the case, would anyone object to 
me changing image to logo in the Pace?
That would be bogus a rule. How does it hurt interop to put an image in 
an entry?

Robert Sayre


Re: xsd:dateTime vs. RFC 3339

2005-02-04 Thread Julian Reschke
Norman Walsh wrote:
/ Julian Reschke [EMAIL PROTECTED] was heard to say:
| - Neither xsd:dateTime nor RFC3339 are perfect for our needs, so we
| may have to profile one of them. In which case I'd prefer to stick
| with RFC3339.
Perhaps a compromise? Date Construct values MUST be valid xsd:dateTime
values and MUST also match the following regular expression:
  [0-9]{8}T[0-9]{2}:[0-9]{2}:[0-9]{2}(\.[0-9]+)?(Z|[\+\-][0-9]{2}:[0-9]{2})
(Expressed for my own testing purposes in XML Schema pattern syntax.)
Sounds good to me, except that I would keep the reference to RFC3339 
(semantics are the same, but I think RFC3339 is more readable).

Best regards, Julian
--
green/bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760


Re: PaceIconAndImage

2005-02-04 Thread Antone Roundy
On Friday, February 4, 2005, at 12:37  PM, Robert Sayre wrote:
Antone Roundy wrote:
Let me restate this in a way that might lead to action: I have a 
sneaking suspicion that we're not going to get consensus on allowing 
image and/or icon in entry.  If that's the case, would anyone object 
to me changing image to logo in the Pace?
That would be bogus a rule. How does it hurt interop to put an image 
in an entry?
Just to be sure this is clear, I am not advocating that limitation--it 
is imposed by the Pace, and I seem to recall hearing opinions on both 
sides about whether entries should have images and/or icons.  I'd be 
happy to allow both, though I doubt icons would get used much in 
entries.  I just want to be sure that if we DON'T allow images in 
entries, we use a name for the element that makes sense to me to limit 
to the feed level.



RE: Call for final Paces for consideration: deadline imminent

2005-02-04 Thread Bob Wyman

Paul Hoffman wrote:
 In specific, a complete archive of all entries in a feed is well
 taken care of by our current format; it's just not explicitly called
 an archive. The fact that our IDs are unique over all time means an
 archive of all entries that were ever in the main feed is just a
 bigger feed; that will work exactly as an archive with no ambiguity
 of elements.
Although I can't find it specified in the current draft, there used
to be a rule that you weren't supposed to use the same atom:id more than
once in a single feed. (This rule is enforced by FeedValidator for Atom 0.3
documents... Sam? Mark?)
If the prohibition against having more than one entry in a single
feed document with the same atom:id is still in effect, (i.e. if you can't
have multiple versions of an entry in a single feed document) then you can't
use an Atom feed document to archive all states or versions of entries as
they have been published over time. You would only be able to archive, at
best, a single version of each entry (typically the last one published, I
think).
One alternative might to be provide an explicit relaxation of the
rules by saying that for at least archives, what must be unique is a
combined key constructed by concatenating atom:id + atom:modified. 

bob wyman




Re: Call for final Paces for consideration: deadline imminent

2005-02-04 Thread Tim Bray
On Feb 4, 2005, at 11:56 AM, Bob Wyman wrote:
	Although I can't find it specified in the current draft, there used
to be a rule that you weren't supposed to use the same atom:id more 
than
once in a single feed. (This rule is enforced by FeedValidator for 
Atom 0.3
documents... Sam? Mark?)
Sounds like a bug to me.  I can't see any reason to rule this out. -Tim


Re: Entry order

2005-02-04 Thread Julian Reschke
Tim Bray wrote:
On Feb 4, 2005, at 11:27 AM, Walter Underwood wrote:
Is this a joke? This is like saying that the order of the entries in my
mailbox is not significant. Note that ordering a mailbox by date is not
the same thing as its native order.

Except for, Atom entries have a *compulsory* updated date.  So I have 
no idea what semantics you'd attach to the natural order... -Tim
Nit: they want have an ordering anymore if we allow updated dates with 
missing timezone information (i.e., dates with a 24h uncertainty).

Julian
--
green/bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760


RE: Call for final Paces for consideration: deadline imminent

2005-02-04 Thread Paul Hoffman
At 2:56 PM -0500 2/4/05, Bob Wyman wrote:
Although I can't find it specified in the current draft, there used
to be a rule that you weren't supposed to use the same atom:id more than
once in a single feed.
The current draft says:
5.8  atom:id Element
   The atom:id element is an Identity construct that conveys a
   permanent, universally unique identifier for an entry.  atom:entry
   elements MUST contain exactly one atom:id element.
That means that you're not allowed to sue the same atom:id in any two 
entries, ever.

If the prohibition against having more than one entry in a single
feed document with the same atom:id is still in effect,
Yes
 (i.e. if you can't
have multiple versions of an entry in a single feed document) then you can't
use an Atom feed document to archive all states or versions of entries as
they have been published over time. You would only be able to archive, at
best, a single version of each entry (typically the last one published, I
think).
The requirement in the charter is:
   * a complete archive of all entries in a feed
Your proposal expands that significantly. If you feel a need for that 
(quite different) kind of archive, you can propose an extension.

One alternative might to be provide an explicit relaxation of the
rules by saying that for at least archives, what must be unique is a
combined key constructed by concatenating atom:id + atom:modified.
We don't need to define archive in the core format spec, certainly 
not in a way that will be confusing to people who only care about 
entries and normal feeds. That's what extensions are for.

--Paul Hoffman, Director
--Internet Mail Consortium


Re: Call for final Paces for consideration: deadline imminent

2005-02-04 Thread Bjoern Hoehrmann

* Paul Hoffman wrote:
  Although I can't find it specified in the current draft, there used
to be a rule that you weren't supposed to use the same atom:id more than
once in a single feed.

The current draft says:

5.8  atom:id Element

The atom:id element is an Identity construct that conveys a
permanent, universally unique identifier for an entry.  atom:entry
elements MUST contain exactly one atom:id element.

That means that you're not allowed to sue the same atom:id in any two 
entries, ever.

It does not mean that once cannot have multiple versions of the same
entry in a feed (or duplicate entries for that matter).
-- 
Björn Höhrmann · mailto:[EMAIL PROTECTED] · http://bjoern.hoehrmann.de
Weinh. Str. 22 · Telefon: +49(0)621/4309674 · http://www.bjoernsworld.de
68309 Mannheim · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/ 



Re: Call for final Paces for consideration: deadline imminent

2005-02-04 Thread Mark Nottingham

On Feb 4, 2005, at 12:29 PM, Paul Hoffman wrote:
At 2:56 PM -0500 2/4/05, Bob Wyman wrote:
	Although I can't find it specified in the current draft, there used
to be a rule that you weren't supposed to use the same atom:id more 
than
once in a single feed.
The current draft says:
5.8  atom:id Element
   The atom:id element is an Identity construct that conveys a
   permanent, universally unique identifier for an entry.  atom:entry
   elements MUST contain exactly one atom:id element.
That means that you're not allowed to sue the same atom:id in any two 
entries, ever.
I don't read it that way, although I understand how you might infer 
that; there's too much wiggle room in the current text for that intent 
to be clear.

I.e., just because it's a permanent, universally unique identifier 
doesn't mean you're not able to use it twice to talk about a single 
entry; to RDF people, this will seem quite natural. If you want to only 
see one instance of an atom:id's content in the set of all entries ever 
published in any feed, you need to say that explicitly.

--
Mark Nottingham http://www.mnot.net/


Re: Call for final Paces for consideration: deadline imminent

2005-02-04 Thread Graham
On 4 Feb 2005, at 8:44 pm, Mark Nottingham wrote:
I.e., just because it's a permanent, universally unique identifier 
doesn't mean you're not able to use it twice to talk about a single 
entry;
I disagree, as I've said before. The only literal interpretation is 
that you can't serve the same entry twice with the same id. We know it 
doesn't mean that, but the spec just doesn't define in which axis 
unique is meant to apply.

Graham

smime.p7s
Description: S/MIME cryptographic signature


Re: Call for final Paces for consideration: deadline imminent

2005-02-04 Thread Tim Bray
On Feb 4, 2005, at 12:44 PM, Mark Nottingham wrote:
That means that you're not allowed to sue the same atom:id in any two 
entries, ever.
I don't read it that way, although I understand how you might infer 
that; there's too much wiggle room in the current text for that intent 
to be clear.

I.e., just because it's a permanent, universally unique identifier 
doesn't mean you're not able to use it twice to talk about a single 
entry; to RDF people, this will seem quite natural. If you want to 
only see one instance of an atom:id's content in the set of all 
entries ever published in any feed, you need to say that explicitly.
I'm with Mnot on this one.  Just because it uniquely identifies an 
entry, that doesn't mean you can't have two versions of the same entry 
in a feed.  Given that entries can show up in more than one feed, it is 
clearly the case that software is going to have to deal with multiple 
entries bearing the same ID in its input stream, so I don't see any 
reason for ruling them out in a single feed.

But, the spec needs to have no wriggle room.  Right now it's silent, it 
should be clear. -Tim



Re: Call for final Paces for consideration: deadline imminent

2005-02-04 Thread Bill de hÓra
Bjoern Hoehrmann wrote:
It does not mean that once cannot have multiple versions of the same
entry in a feed (or duplicate entries for that matter).
Conversely it does imply that if you do, you may (and possibly, must) 
assume that they are the same entry.

The problem: there's no easy way to distinguish between entry states and 
defective id allocation.

cheers
Bill


Re: Call for final Paces for consideration: deadline imminent

2005-02-04 Thread Robert Sayre
Graham wrote:
On 4 Feb 2005, at 8:44 pm, Mark Nottingham wrote:
I.e., just because it's a permanent, universally unique identifier 
doesn't mean you're not able to use it twice to talk about a single 
entry;

I disagree, as I've said before. The only literal interpretation is that 
you can't serve the same entry twice with the same id. We know it 
doesn't mean that, but the spec just doesn't define in which axis 
unique is meant to apply.
Hmm. The things URIs identify can change. What we really want to say is 
don't be a bother and produce different entries with the same id and 
don't expect clients to keep separate records of entries with the same 
id. We should probably be more worried about bad implementions totally 
missing the point of identifiers, than about good implementations with 
sophisticated notions of versioning and identifiers.

Robert Sayre


Re: Entry order

2005-02-04 Thread Walter Underwood

--On February 4, 2005 11:44:31 AM -0800 Tim Bray [EMAIL PROTECTED] wrote:
 On Feb 4, 2005, at 11:27 AM, Walter Underwood wrote:
 
 Is this a joke? This is like saying that the order of the entries in my
 mailbox is not significant. Note that ordering a mailbox by date is not
 the same thing as its native order.
 
 Except for, Atom entries have a *compulsory* updated date.  So I have no
 idea what semantics you'd attach to the natural order... -Tim

Order the publisher wants to present them in. Conventionally, most recently
published first. Entries may be updated without being reordered.

If clients are told to ignore the order, and given only an updated timestamp,
there is no way to show most recent headlines, which is the primary 
purpose of the whole family of RSS formats.

Right now, you can shuffle the entries and Atom says it is the same feed.

Either we need a published date stamp or we need to honor the order.

wunder
--
Walter Underwood
Principal Architect, Verity



Re: Call for final Paces for consideration: deadline imminent

2005-02-04 Thread Henry Story
A really clear way to specify this is to say that an id is a functional 
relation between
an entry and a identity construct.

This implies:
 -An Entry can only have one id.
 -Different Entries can have the same id.
Of course because there is a bit of a confusion as to what is meant by 
an Entry
the above sounds paradoxical.

It is a bit like the relation the body of a US citizen has to a social 
security number.
The body of a US citizen at a time has a functional relation to a SS 
number. Any such body
has only one SS number. But because when we eat and breath our bodies 
change it turns out
that different bodies have a relation to the same SS number. The 
different bodies, are time
slices of the same US citizen. The group of these time slices is 
identified by the social
security number. So that the relation between the SS number and  set of 
such citizen slices,
namely the relation between a SS number and the citizen is both 
functional and inverse functional.

When this group speaks about an Entry as it appears in the Feed
feed
entry
idtag:bblfish.net/entry1/id
...
/entry
...
/feed
you are really speaking about an entry version. But because when people 
sit down and write
an entry they are looking at the present version of the entry, and this 
is what they use
to identify the sequence of entries that form the unique Entry over 
time, there is a confusion
of what is being talked about.

It is a little as if I spoke to someone and identified the body I am 
seeing at present
with the person that body is a temporal part of.

So when above I say:
 -An Entry can only have one id.
 -Different Entries can have the same id.
  What we mean is
 - the Entry Version can only have one id
 - any two Entry Versions that have the same id are different versions 
of the same Entry.

So now one should define what that type of entry is. And that is 
simple. It is the Collection
of all Entry Versions that have the same id.

Henry
On 4 Feb 2005, at 22:10, Mark Nottingham wrote:
Graham, the issue here is that the spec can be interpreted in a number 
of ways, which is not good. You seem to agree with that below, 
correct?

Separately, there's the issue of what it *should* say. Tim and now you 
say that you have a good idea of what you want it to say; I'd be very 
interested to see how you'd specify that. Can you suggest some spec 
text?

On Feb 4, 2005, at 1:00 PM, Graham wrote:
On 4 Feb 2005, at 8:44 pm, Mark Nottingham wrote:
I.e., just because it's a permanent, universally unique identifier 
doesn't mean you're not able to use it twice to talk about a single 
entry;
I disagree, as I've said before. The only literal interpretation is 
that you can't serve the same entry twice with the same id. We know 
it doesn't mean that, but the spec just doesn't define in which axis 
unique is meant to apply.

Graham
--
Mark Nottingham http://www.mnot.net/



Re: Call for final Paces for consideration: deadline imminent

2005-02-04 Thread Graham
On 4 Feb 2005, at 9:10 pm, Mark Nottingham wrote:
Separately, there's the issue of what it *should* say. Tim and now you 
say that you have a good idea of what you want it to say; I'd be very 
interested to see how you'd specify that. Can you suggest some spec 
text?
As I suggested a couple of days ago:
Any two versions of the same entry must use the same id, [which 
requires that all characters are the same]. Any two different entries 
must have different ids, [which requires that at least one character is 
different].

Graham

smime.p7s
Description: S/MIME cryptographic signature


Re: Call for final Paces for consideration: deadline imminent

2005-02-04 Thread Robert Sayre
Tim Bray wrote:
I'm with Mnot on this one.  Just because it uniquely identifies an 
entry, that doesn't mean you can't have two versions of the same
entry in a feed.  ... I don't see any reason for ruling them out in a
single feed.
Robert Sayre wrote:
We should probably be more worried about bad implementions totally
missing the point of identifiers, than about good implementations
with  sophisticated notions of versioning and identifiers.
With that in mind, I'm going to agree with Graham. What will happen is 
that super-simple implmentations that don't keep state will show both 
instances, because they don't bother with GUIDs. Then Graham will get 
bug reports saying This feed only has nine entries in Shrook, but ten 
entries in TrivialServerSideScriptX, why is Shrook so broken? We need 
to make that feed invalid, and Graham's life easier. Sophisticated 
implementations can assert common ancestry with an extension element.

Robert Sayre


Re: PaceExtendingAtom

2005-02-04 Thread Mark Nottingham
It certainly gives the impression that there's a preference; it's like 
saying The language of the feed SHOULD be English; there are lots of 
options, and we don't require one, but it does call one out.

Why is this a normative requirement, and what does adding this sentence 
bring to the spec?

On Feb 3, 2005, at 11:27 PM, Tim Bray wrote:
On Feb 3, 2005, at 8:17 PM, Mark Nottingham wrote:
This specification describes Atom's XML markup vocabulary.  
Markup from
other vocabularies (foreign markup) can be used in Atom in 
a variety of
ways. Text Constructs may contain foreign markup which 
SHOULD be HTML or
XHTML.
What does this statement add? Why is HTML or XHTML normatively 
preferred over text, MathML, or any other vocabulary?
It's not preferred over text, you can say type='TEXT', but since this 
is a *text* construct and quite likely to be presented in rows  
columns (title, author, etc) simpler is better, so I'd think the 
SHOULD is sensible here. -Tim


--
Mark Nottingham http://www.mnot.net/


Re: Call for final Paces for consideration: deadline imminent

2005-02-04 Thread Graham
On 4 Feb 2005, at 10:09 pm, Mark Nottingham wrote:
The term version seems out of place here. What you're saying, in 
effect, is that the ID acts as a hash of entry's content, correct? If, 
so, what value does it bring?
Pardon:
Any two versions of the same entry must use the same id, [which 
requires that all characters are the same]. Any two different entries 
must have different ids, [which requires that at least one character 
is different].
It says different versions must have the same id. How is that a hash?
Graham


smime.p7s
Description: S/MIME cryptographic signature


Re: Call for final Paces for consideration: deadline imminent

2005-02-04 Thread Antone Roundy
On Friday, February 4, 2005, at 02:05  PM, Tim Bray wrote:
On Feb 4, 2005, at 12:44 PM, Mark Nottingham wrote:
That means that you're not allowed to sue the same atom:id in any 
two entries, ever.
I don't read it that way, although I understand how you might infer 
that; there's too much wiggle room in the current text for that 
intent to be clear.

I.e., just because it's a permanent, universally unique identifier 
doesn't mean you're not able to use it twice to talk about a single 
entry; to RDF people, this will seem quite natural. If you want to 
only see one instance of an atom:id's content in the set of all 
entries ever published in any feed, you need to say that explicitly.
I'm with Mnot on this one.  Just because it uniquely identifies an 
entry, that doesn't mean you can't have two versions of the same entry 
in a feed.  Given that entries can show up in more than one feed, it 
is clearly the case that software is going to have to deal with 
multiple entries bearing the same ID in its input stream, so I don't 
see any reason for ruling them out in a single feed.

But, the spec needs to have no wriggle room.  Right now it's silent, 
it should be clear. -Tim
The following language should make things clear:
First, if we want to be able to put multiple revisions of an entry into 
a single Atom Feed Document (note: I'm talking about a document, not 
the abstraction called a feed), or multiple portions or versions of a 
feed into a single Atom Aggregation Document, if such a thing ever 
comes to exist:

An Atom Document MAY contain multiple versions of the same resource, 
in which case the content of the Identity construct for each would be 
identical.

Second, if we don't want that to be possible:
An Atom Document MUST NOT contain more than one version of the same 
resource.  Thus, no two resources in a single Atom Document can have 
the same content in their Identity constructs.



Re: PaceExtendingAtom

2005-02-04 Thread Mark Nottingham
Baking this as a normative requirement -- even a SHOULD -- into a 
standards-track RFC is a bad idea.

These formats are not the only interoperable formats on the planet, and 
in fact they all have interop problems to some degree.

In five years, this requirement isn't going to make any sense.
I've said my piece on this one; I'm interested in responses to my other 
questions and points.

Cheers,
On Feb 4, 2005, at 2:15 PM, Robert Sayre wrote:
Mark Nottingham wrote:
It certainly gives the impression that there's a preference; it's 
like saying The language of the feed SHOULD be English; there are 
lots of options, and we don't require one, but it does call one out.
Why is this a normative requirement, and what does adding this 
sentence bring to the spec?
TEXT, HTML, and XHTML are preferred because they interoperate.
there may exist valid reasons in particular circumstances to ignore a 
particular item, but the full implications must be understood and 
carefully weighed before choosing a different course.

Seems right to me. If MathML titles become wildly popular, the spec 
can be revised later on.

Robert Sayre

--
Mark Nottingham http://www.mnot.net/


Re: Entry order

2005-02-04 Thread Roger B.

 If clients are told to ignore the order, and given only an updated timestamp,
 there is no way to show most recent headlines...

At a single moment within a feedstream, sure... but the next time an
entry is added to that feed, I'll have no problem letting the user
know that this is new stuff.

 Either we need a published date stamp or we need to honor the order.

Maybe I've missed something amidst the chao-- enthusiastic array of
Paces lately, but don't we *have* a published date?

--
Roger Benningfield
JournURL



Re: Call for final Paces for consideration: deadline imminent

2005-02-04 Thread Mark Nottingham
When you talk about characters being the same or different, are you 
saying in the entry, or in the id?

On Feb 4, 2005, at 2:18 PM, Graham wrote:
On 4 Feb 2005, at 10:09 pm, Mark Nottingham wrote:
The term version seems out of place here. What you're saying, in 
effect, is that the ID acts as a hash of entry's content, correct? 
If, so, what value does it bring?
Pardon:
Any two versions of the same entry must use the same id, [which 
requires that all characters are the same]. Any two different 
entries must have different ids, [which requires that at least one 
character is different].
It says different versions must have the same id. How is that a hash?
Graham
--
Mark Nottingham http://www.mnot.net/


Re: PaceRemoveVersionAttr

2005-02-04 Thread Joe Gregorio

On Thu, 03 Feb 2005 19:56:32 -0500, Sam Ruby [EMAIL PROTECTED] wrote:
 For me, I'd like the comfort of knowing that a V1.0 feed will continue
 to be valid with respect to future versions of the specifications, and
 that tools written to consume V1.0 feeds will continue to work with
 subsequent versions of the specification.
 
 RSS 0.9x (including 2.0) is evidence that the former is possible (I can
 cite some minor incompatibilities, but these are merely exceptions that
 prove the rule).  I do believe that the latter is also possible.
 
 Without ever changing the namespace.

+1

And +1 to PaceRemoveVersionAttr, particularly in light
of Atom being a Must Understand vocabulary.

-- 
Joe Gregoriohttp://bitworking.org



Re: Call for final Paces for consideration: deadline imminent

2005-02-04 Thread Graham
On 4 Feb 2005, at 10:32 pm, Mark Nottingham wrote:
When you talk about characters being the same or different, are you 
saying in the entry, or in the id?
Oh, right. The id. That would be clear if the things in brackets were 
expanded (since same and different ids also need defining).

Graham


smime.p7s
Description: S/MIME cryptographic signature


Re: Call for final Paces for consideration: deadline imminent

2005-02-04 Thread Paul Hoffman
At 1:05 PM -0800 2/4/05, Tim Bray wrote:
On Feb 4, 2005, at 12:44 PM, Mark Nottingham wrote:
That means that you're not allowed to sue the same atom:id in any 
two entries, ever.
I don't read it that way, although I understand how you might infer 
that; there's too much wiggle room in the current text for that 
intent to be clear.

I.e., just because it's a permanent, universally unique 
identifier doesn't mean you're not able to use it twice to talk 
about a single entry; to RDF people, this will seem quite natural. 
If you want to only see one instance of an atom:id's content in the 
set of all entries ever published in any feed, you need to say that 
explicitly.
I'm with Mnot on this one.
So am I; I should have sad ...in any two different entries, ever. 
And an archive of a feed can have the entry many times, no problem.

--Paul Hoffman, Director
--Internet Mail Consortium


Re: PaceProfile - new

2005-02-04 Thread Mark Nottingham
Hmm. I'm thinking of profiles as fairly coarse-grained things; so 
coarse-grained, it wouldn't make sense to mix-and-match them in a 
single document (or, if you do, you either don't use a profile, or you 
invent a new one).

I.e., does it make sense to mix a stock quote entry with a systems 
monitoring or blog entry? How would a UA present this?

On Feb 4, 2005, at 8:15 AM, Bill de hÓra wrote:
Mark Nottingham wrote:
Bill,
I'm sorry, I don't think I get what you're saying; the words all make 
sense, but I don't know how you got here.
[../]
The Pace doesn't place any requirements on Atom Processors WRT 
@profile; it's just an advisory flag that tells it what kinds of 
metadata it can count on appearing in the feed.
Ok, I'll calm down and try again.
If the advisory @profile scopes at the level of the feed, I think 
that's too broad a scope. It needs to scope at the level of the entry, 
or it's liable to becomes meaningless when entries are mixed and 
matched. I can barely figure out how to class individual entries, 
never mind entire feeds. Maybe there's a use case I'm not getting.
--
Mark Nottingham   Principal Technologist
Office of the CTO   BEA Systems



RE: Call for final Paces for consideration: deadline imminent

2005-02-04 Thread Bob Wyman

Paul Hoffman wrote:
 That means that you're not allowed to [use] the same atom:id in any
 two entries, ever.
We have atom:modified in order to indicate that an instance is a
modified version of a previously published entry. The linkage between the
two instances of the entry is that they share a common atom:id.
Forcing each instance of each entry to have a unique id would make
it impossible for us to do what users expect us to do in one aspect of
duplicate detection. i.e. Users don't normally want to see ever state of
an entry as it develops over time, what they typically want to see is the
most recent state of the entry. To provide this, we need a way to link
together the various versions or states of the entry -- that is done with
atom:id. Priority of the versions is determined using atom:modified...

bob wyman





Re: PaceProfile - new

2005-02-04 Thread James M Snell
It would make sense to mix syndication, archive, aggregation, etc.
 In other words, some profiles would make sense to mix together.
Entry-scoped profile makes a LOT of sense.
@profile attribute on the feed level applies only to the feed and is
used to identify the collection(s) of metadata elements used in the feed.
@profile attribute on the entry level applies only to the entry and is
used to identify the collection(s) of metadata elements used in the entry.
feed profile=syndication aggregation
  ...
  entry profile=blog
   ...
  /entry
/feed
feed profile=archive
  ...
  entry profile=blog archive
...
  /entry
/feed
Other than helping to identify the collection of metadata elements,
another nice about this approach is that it allows the producer of the
feed to explicitly indicate the purpose of the feed.  Feeds that are
intended for archiving use can be handled differently than feeds that
are intended for syndication.  Entries that use a blog profile can be
handled differently than entries used, for instance, to express CAP
Alert information, etc.
As for profiles that don't make sense to mix and match, leave the
decision about whether to mix and match up to the producer of the
feed/entry.  If the UA detects that a feed/entry uses a combination of
profiles that are contradictory, the UA can choose to either reject the
item or choose to ignore one or both of the profiles and attempt to deal
with the entry by falling back on the default core metadata elements.
If a profile is indicated that the UA does not understand, the UA could
safely ignore the profile and just work off the minimally required core
metadata elements.
- James M Snell
Mark Nottingham wrote:
Hmm. I'm thinking of profiles as fairly coarse-grained things; so 
coarse-grained, it wouldn't make sense to mix-and-match them in a single 
document (or, if you do, you either don't use a profile, or you invent a 
new one).

I.e., does it make sense to mix a stock quote entry with a systems 
monitoring or blog entry? How would a UA present this?

On Feb 4, 2005, at 8:15 AM, Bill de hÓra wrote:
Mark Nottingham wrote:
Bill,
I'm sorry, I don't think I get what you're saying; the words all make 
sense, but I don't know how you got here.
[../]
The Pace doesn't place any requirements on Atom Processors WRT 
@profile; it's just an advisory flag that tells it what kinds of 
metadata it can count on appearing in the feed.

Ok, I'll calm down and try again.
If the advisory @profile scopes at the level of the feed, I think 
that's too broad a scope. It needs to scope at the level of the entry, 
or it's liable to becomes meaningless when entries are mixed and 
matched. I can barely figure out how to class individual entries, 
never mind entire feeds. Maybe there's a use case I'm not getting.

--
Mark Nottingham   Principal Technologist
Office of the CTO   BEA Systems




Re: Call for final Paces for consideration: deadline imminent

2005-02-04 Thread Antone Roundy
On Friday, February 4, 2005, at 03:12  PM, Antone Roundy wrote:
An Identity construct is an element whose content conveys an 
unchanging identifier which MUST be universally unique within Atom 
Documents to the set of all versions and instantiations of the 
resource that the construct's parent instantiates.
Okay, getting serious now, there is room for clarification.  How about 
we replace this:

3.5  Identity Constructs
An Identity construct is an element whose content conveys a permanent, 
universally unique identifier for the construct's parent.
with this:
3.5  Identity Constructs
An Identity construct is an element whose content conveys a permanent, 
universally unique identifier for the resource (instantiated|described) 
by the construct's parent element.  An Atom Document MAY contain 
multiple (revisions|versions) of the same resource, in which case the 
content of the Identity construct for each would be identical. 
Applications MAY decline to display more than one version of each 
resource.

Comments?  Preferences?  Better ideas?  Is it ready for a Pace?


Re: PaceProfile - new

2005-02-04 Thread James Snell

Absolutely, there would be a core default profile defined in the Atom
syntax spec.  @profiles=core syndication @profiles=core blog, etc.


On Fri, 4 Feb 2005 15:19:59 -0800, Mark Nottingham [EMAIL PROTECTED] wrote:
 
 On Feb 4, 2005, at 3:13 PM, James M Snell wrote:
 
   If a profile is indicated that the UA does not understand, the UA
  could safely ignore the profile and just work off the minimally
  required core metadata elements.
 
 Ah, that's the rub; I'm trying to say that that set of 'core' elements
 is, in and of itself, a profile.
 
 
 --
 Mark Nottingham http://www.mnot.net/
 
 


-- 
- James Snell
  http://www.snellspace.com
  [EMAIL PROTECTED]



Re: Call for final Paces for consideration: deadline imminent

2005-02-04 Thread Robert Sayre
Antone Roundy wrote:
3.5  Identity Constructs
An Identity construct is an element whose content conveys a permanent, 
universally unique identifier for the resource (instantiated|described) 
by the construct's parent element.  An Atom Document MAY contain 
multiple (revisions|versions) of the same resource, in which case the 
content of the Identity construct for each would be identical. 
Applications MAY decline to display more than one version of each resource.

Comments?  Preferences?  Better ideas?  Is it ready for a Pace?
It doesn't make a bit of sense unless you define entry and feed, as 
has been pointed out numerous times over the past few days. This text is 
defining a feed in the text on atom:id, which should be short.

If you define feed as a sliding window on a stream of entries, your 
definition makes sense. If you define feed as a server-determined 
representation of the current status of a set of entries, then it only 
makes sense to include one entry per atom:id. I would argue the second 
definition makes a lot more sense and accurately reflects real-world 
usage, where even the RDF formats recommend against repeating rdf:about.

Robert Sayre


Re: Entry order

2005-02-04 Thread Walter Underwood

--On February 4, 2005 4:28:53 PM -0600 Roger B. [EMAIL PROTECTED] wrote:
 If clients are told to ignore the order, and given only an updated timestamp,
 there is no way to show most recent headlines...
 
 At a single moment within a feedstream, sure... but the next time an
 entry is added to that feed, I'll have no problem letting the user
 know that this is new stuff.

But if three are added, you can't order those three. 

wunder
--
Walter Underwood
Principal Architect, Verity



Re: Call for final Paces for consideration: deadline imminent

2005-02-04 Thread Mark Nottingham
Just a note; I'm planning to remove the Identity Construct from -06, 
because it's only used in one place (the definition of atom:id). 
Otherwise, this sounds like a reasonable start.

On Feb 4, 2005, at 3:23 PM, Antone Roundy wrote:
On Friday, February 4, 2005, at 03:12  PM, Antone Roundy wrote:
An Identity construct is an element whose content conveys an 
unchanging identifier which MUST be universally unique within Atom 
Documents to the set of all versions and instantiations of the 
resource that the construct's parent instantiates.
Okay, getting serious now, there is room for clarification.  How about 
we replace this:

3.5  Identity Constructs
An Identity construct is an element whose content conveys a 
permanent, universally unique identifier for the construct's parent.
with this:
3.5  Identity Constructs
An Identity construct is an element whose content conveys a permanent, 
universally unique identifier for the resource 
(instantiated|described) by the construct's parent element.  An Atom 
Document MAY contain multiple (revisions|versions) of the same 
resource, in which case the content of the Identity construct for each 
would be identical. Applications MAY decline to display more than one 
version of each resource.

Comments?  Preferences?  Better ideas?  Is it ready for a Pace?

--
Mark Nottingham   Principal Technologist
Office of the CTO   BEA Systems


Re: Call for final Paces for consideration: deadline imminent

2005-02-04 Thread Tim Bray

On Feb 4, 2005, at 3:23 PM, Antone Roundy wrote:
On Friday, February 4, 2005, at 03:12  PM, Antone Roundy wrote:
An Identity construct is an element whose content conveys an 
unchanging identifier which MUST be universally unique within Atom 
Documents to the set of all versions and instantiations of the 
resource that the construct's parent instantiates.
Okay, getting serious now, there is room for clarification.  How about 
we replace this:
You guys are making good progress, I'm impressed.  Now please don't 
forget to Pace-ify whatever you end up with for Monday. -Tim



RE: Call for final Paces for consideration: deadline imminent

2005-02-04 Thread Bob Wyman

Clearly, I meant atom:updated not atom:modified... My apologies for the
slip.

bob wyman

-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Tim Bray
Sent: Friday, February 04, 2005 7:11 PM
To: [EMAIL PROTECTED]
Cc: 'Mark Nottingham'; 'Paul Hoffman'; 'Atom WG'
Subject: Re: Call for final Paces for consideration: deadline imminent


On Feb 4, 2005, at 2:43 PM, Bob Wyman wrote:

 Paul Hoffman wrote:
 That means that you're not allowed to [use] the same atom:id in any
 two entries, ever.
   We have atom:modified in order to indicate that an instance is a
 modified version of a previously published entry.

We do?  I don't think so. -Tim





Re: PaceProfile - new

2005-02-04 Thread Graham
On 5 Feb 2005, at 12:09 am, Mark Nottingham wrote:
I was thinking of profiles only specifying:
  - what metadata is required to be present
  - optionally for each one that's required, the maximum number that 
can be present

If profiles are constrained as such, they're pretty trivial to 
compose; if we allow them to say what *isn't* allowed to be there, it 
gets much more complex. It also goes against the spirit of 
extensibility...
I fail to see what constraints in the current version justify different 
profiles, especially given the inevitable breaks in interop. Can you 
give us some examples?

Graham

smime.p7s
Description: S/MIME cryptographic signature


Re: Posted PaceEntryOrder (was Entry order)

2005-02-04 Thread Graham
On 3 Feb 2005, at 12:18 am, David Powell wrote:
{{{ This specification assigns no significance to the order of
atom:entry elements within the feed. Processors MAY present entries in
a different order to which they are appear in an Atom Feed Document.
}}}
First sentence no, but the second sentence says all that we need to say 
and no more.

Graham

smime.p7s
Description: S/MIME cryptographic signature


Re: PaceRemoveVersionAttr

2005-02-04 Thread Graham
On 3 Feb 2005, at 9:36 pm, Graham wrote:
On 3 Feb 2005, at 9:18 pm, Norman Walsh wrote:
I think, on balance, I'm +1 for keeping it, but I doubt I'd lie down
in the road over it.
Yes. I like it too.
Just to clarify, I like it being there for 
informational/statistics/debugging purposes. I don't see what harm it 
causes or why there's any need to remove it.

Graham


smime.p7s
Description: S/MIME cryptographic signature


Re: PaceHeadless

2005-02-04 Thread Robert Sayre
Graham wrote:
-1
Putting everything in one group and requiring it to be first is useful, 
and also adds consistency to head-in-entry, as evidenced by the 
introduction of the feeder element. Also feeder is a horrible word.
And head doesn't suck? I struggle to type a sentence on the subject 
without making an unintentional pun. source-feed is fine. The section 
on atom:head is totally confusing and bad--it's easier if you just do it 
the way PubSub does it *right now*.

Robert Sayre


Don't mess with HeadInEntry!

2005-02-04 Thread Bob Wyman

Robert Sayre wrote:
 HeadInEntry is trivial to do as an extension, so there's no 
 reason to leave it in.
There are a number of excellent reasons to leave it in!

1. Just about the only functional advantage that Atom has over RSS
is that HeadInEntry provides core support for aggregated feeds. If you're
unwilling to innovate in even this one tiny spot, why the heck bother with
this effort at all? Perhaps we should all join Dare over in RSS-land... With
Microsoft being so anti-Atom, we need *some* argument for expending the
effort and political capital needed to support this format!
2. The Internet Draft Atom over XMPP requires HeadInEntry in order
to provide attribution for entries.
3. Entry Documents will often need HeadInEntry to identify their
origin.
4. We've been talking about HeadInEntry ever since I proposed it
back in June at the Atom Community meeting. On numerous occasions, the group
as a whole has rejected the various feed of feed proposals as overly
complex and unnecessary. It is a bit bizarre to see all this being rehashed
in a rush as we drive towards a Last Call. 
5. If HeadInEntry is not in the core, it will not be widely
implemented by clients. Given the speed with which the IETF approves RFC's
it is also likely that it would be a *long* time before an extension RFC
could get approved -- yet we need HeadInEntry TODAY! The reduced penetration
of HeadInEntry that would come from it being defined in a future extension
makes it largely useless and not worth the effort to even try to get a
formal extension. What you'll be doing is forcing people who are in the
aggregation business to define private extensions to address these issues
and to do so outside the Atom process. We have work to do and customers to
serve. We can't just put our businesses on hold for years...
6. All of the alternatives that have been proposed require drastic
and unlikely modifications to the design and architecture of readers. (i.e.
stuff like adding an aggregation document!!) Such proposals are not viable
alternatives no matter how sweet one might find their abstractions...
7. We at PubSub have had running code since July that demonstrates
the utility of HeadInEntry (i.e. our ps:source-feed). None of the other
proposals that have been made are supported or proven by running-code.
There is no field experience in their use. I have also not seen any
alternatives proposed by anyone who actually appears to be in the feed
aggregation business...

We decided to support HeadInEntry. It doesn't make sense to back off
now. Deferring HeadInEntry to a non-core extension essentially kills it and
ensures that Atom use will provide virtually no advantage to anyone who is
building aggregated feeds.

bob wyman






Re: Open Comments.....

2005-02-04 Thread Roger B.

  Any feedback on this guys?  Curious to see what type of interest there is
 here...

Kevin: Why would anyone want to fiddle around with HTML classes to
indicate comments when they can just publish/consume comment feeds? Or
did I misinterpret the purpose of the effort?

--
Roger Benningfield
JournURL