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
On Feb 3, 2005, at 2:03 PM, Norman Walsh wrote:
I find the constraint that an atom:feed or atom:entry can contain at
most one atom:contributor a little odd. Suppose Tom, Dick, and Harry
work on an entry, why can only two of them get credit (one as author
and one as contributor). Why am I not
On Feb 2, 2005, at 12:15 PM, Robert Sayre wrote:
1.) A web forum, where one post serves as the root of a collection of
other posts.
HTML--
http://groups-beta.google.com/group/bloggerDev/
Atom 0.3, root posts only--
http://groups-beta.google.com/group/bloggerDev/feed/topics.xml
On Feb 2, 2005, at 5:46 PM, Paul Hoffman wrote:
...
On Monday, Feb. 7, the Working Group's final queue rotation will
consist of all Paces open at that time. Any Paces that have obvious
holes in them (to be filled in later, more needs to go here, etc.)
will be ignored. We have had over a year of
On Feb 3, 2005, at 7:06 PM, Graham wrote:
On the other hand, the notion that sometimes you have collections of
feeds is easy to understand, easy to verbalize, and widely evidenced
in practice (cf PubSub friends), if not perhaps widely seen outside
of geekland. So I think I'm +1 on
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
On Feb 2, 2005, at 4:29 AM, Sam Ruby wrote:
Norm's RNC schema was very valuable in debugging, not that there were
many bugs. Check it out at http://www.tbray.org/ongoing/ongoing.atom
the xmlns and version indicate format-04.
I didn't want to fiddle with Norm's RNC.
P.S. w.r.t. the version
On Feb 2, 2005, at 8:22 AM, Sam Ruby wrote:
Much to my surprise, scanning the current document, I don't see any
must ignore text.
Hey, we just accepted PaceExtendingAtom 24 hours or so back, give Rob
Mark a chance :)
On Feb 2, 2005, at 10:29 AM, Robert Sayre wrote:
http://www.intertwingly.net/wiki/pie/PaceRemoveInfoAndHost
+1 -Tim
On Feb 2, 2005, at 11:58 AM, James Snell wrote:
I'm just thinking ahead a bit on this, but I am wondering if it would
be possible for those of us interested in proposing non-core
extensions to Atom to use the Wiki as the forum for sharing proposals
for extensions once the core syntax has been
On Feb 1, 2005, at 1:09 AM, Martin Duerst wrote:
http://www.w3.org/MarkUp/2004/xhtml-faq#xmlspace cites a quite
different
opinion on this matter...
Yes, well that opinion is (a) specific to HTML and (b) wrong. I'm
amazed that the W3C allowed that to be published. -Tim
Would you mind
On Jan 31, 2005, at 10:16 PM, Roy T. Fielding wrote:
Over-specification is just too fun. So that would mean I am
required by Atom format to treat two different entries with the id
http://tbray.org/uid/1000;
as the same entry, even when I received the first one
from tbray.org and the second
On Feb 1, 2005, at 1:05 PM, Julian Reschke wrote:
Currently, the format spec has a normative reference to the protocol
spec (and also defines elements for the service URIs, for instance,
atom:introspection).
I suggest this can and should be removed. --Tim
On Feb 1, 2005, at 4:28 PM, Roy T. Fielding wrote:
Anyone who subscribes to aggregations (for example, I subscribe to
the planetsun.org aggregated feed), is used to seeing the same entry
over and over and over again. This problem is only going to get
worse. With Atom's ID semantics and
Just to see if it uncovered any problems, I twiddled the ongoing
software to generate a format-05 atom feed. It didn't uncover any
problems that I could see. Norm's RNC schema was very valuable in
debugging, not that there were many bugs. Check it out at
Having produced my own Atom feed has made me a supporter of this Pace;
without getting too deep into it link rel=self feels quite sensible,
while link rel=icon feels stupid.
However, this Pace needed work; first of all, it was based on link
constructs, which no longer exist. So I revised it.
On Jan 31, 2005, at 4:37 AM, Robert Sayre wrote:
05-C05, 4.15.3 processing model
If the value of type begins with text/ the content of
atom:content MUST NOT contain child elements.
See 4.15.2: so is this a SHOULD or a MUST?
It's a MUST, and not an editorial change.
If it's a MUST then
On Jan 31, 2005, at 5:37 AM, Bjoern Hoehrmann wrote:
* Tim Bray wrote:
Currently, the draft says *nothing* about xml:space (unless I'm
mis-using the search function). If you read the specification for
xml:space (http://www.w3.org/TR/REC-xml/#sec-white-space), all it says
On Jan 31, 2005, at 8:47 AM, Robert Sayre wrote:
Paul Hoffman wrote:
At 10:30 PM -0500 1/30/05, Robert Sayre wrote:
Well, it seems silly to use a dereferencable scheme if you don't
want the URI dereferenced.
I agree, but there was broad WG consensus on this months ago. It is
too late to revisit
On Jan 31, 2005, at 8:20 PM, Graham wrote:
This makes it clear that we are talking about here is how
you do it, rather than here's one way to do it.
We might be treading on toes making that assertion.
Yes, but it's not only correct, it's good advice, so we should put it
in.
4) Add a
On Jan 30, 2005, at 7:58 AM, Bill de hÓra wrote:
Here are some detailed obs on reading the latest draft.
Excellent, Bill, thanks.
** 1. Introduction
I don't think further discussion on motivation or principles is
needed; on that basis the [[more motivation/design principles]] memo
could be
On Jan 30, 2005, at 9:50 AM, Graham wrote:
2) An intermediary automatically c14nizes all URIs it processes. If
URIs come pre-c14nized from the publisher, this won't do any damage.
This is valid, but the problem is that these intermediaries are
currently imaginary.
I may be moving toward
On Jan 30, 2005, at 9:34 AM, Sam Ruby wrote:
== Abstract ==
Order the Element Definitions in the specification alphabetically.
+1 -Tim
On Jan 30, 2005, at 10:35 AM, Julian Reschke wrote:
That's an implementation issue that shouldn't affect the format.
Without any comment on the issue Julian was addressing, the above is
outrageous. Implementation issues are extremely material in discussion
of the format. Perhaps more material
On Jan 30, 2005, at 12:21 PM, Julian Reschke wrote:
The issues were collected after reading the spec top-to-bottom, and
trying to produce an Atom-05 feed from an existing RSS-1.0 feed
through XSLT. Most of them are editorial.
Good stuff, Julian.
If the value of type begins with text/ or ends
On Jan 30, 2005, at 7:10 PM, Paul Hoffman wrote:
The content of an Identity construct SHOULD NOT be dereferenced,
even when it comes from a
normally dereferencable scheme. There is no requirement for the
content to represent a URI
where a version of the feed or entry may be found.
I'm
On Jan 30, 2005, at 8:09 PM, Robert Sayre wrote:
Yay! Let's drop atom:host.
+1 oh yes please, I always thought it was lame-ass. -Tim
On Jan 26, 2005, at 7:27 AM, Graham wrote:
Very, very good point. The text needs something along the lines of
Atom producers MUST NOT expect consumers which found the document at
a different URI to switch to requesting it from the URI specified.,
or something less clunky. Otherwise it's going
On Jan 26, 2005, at 12:44 PM, Henri Sivonen wrote:
What's the difference between:
atom:title type='TEXT'I do not like
![CDATA[]]marqueegt;/atom:title
and
atom:title type='XHTML'I do not like
![CDATA[]]marqueegt;/atom:title
?
Shouldn't both render as I do not like marquee?
Yeah, but if you
On Jan 26, 2005, at 1:31 PM, Henri Sivonen wrote:
But if you can always substitute type='TEXT' with type='XHTML' but not
the other way round, what's the point of having type='TEXT' in the
spec?
With type='TEXT' you know it's not going to contain any (X)HTML
formatting, so you don't have to
On Jan 26, 2005, at 5:54 PM, Brent Simmons wrote:
I agree with that. It's something many feed producers care about -- I
get email just about every day asking how to make a favicon appear in
my software. And I always wish I could say that there's a way to
specify it in the feed.
I would favor
On Jan 26, 2005, at 7:25 PM, Sam Ruby wrote:
http://lists.w3.org/Archives/Public/www-html/2003Jun/0132.html
For quite some time, my XHTML has contained the following:
link rel=shortcut icon href=/favicon.ico/
Question: would it be of value to people like Graham and Brent if we
were to
Sam has updated our Public Issues List, and Paul has talked about about
where we'd like to get to. I'm about to send fifteen separate
messages, one for each of the 15 (!) format-related Paces up for their
(hopefully) last go-around.
These are the result of discussion between Paul and Sam and
If there were no further discussion: This has received no -1s, but also
not a lot of wild enthusiasm. Support at the moment is a bit marginal,
but some +1s from implementors would probably make it a slam-dunk.
-Tim
If there were no further discussion: This is a radical change to the
document and, so far, hasn't gathered widespread enough support to make
it over the line. -Tim
If there were no further discussion: This topic was beaten to death a
few times in the WG. Unless there is a wave of enthusiasm unaccompanied
by -1s, the dates in the current Internet Draft will be all that ships
with the final document.
-Tim
If there were no further discussion: This is the result of a lot of
discussion around Must Ignore and has in various drafts received lots
of friendly remarks and suggestions for improvement, which have been
incorporated. Absent some convincing -1s, it probably goes in. -Tim
On Jan 24, 2005, at 5:02 PM, Joe Gregorio wrote:
It reads like more of a guideline than a Pace. Inspecting the format
for conformance to these guidelines and generating Paces for
non-conformances seems like a better way to proceed than to actually
add this text to the spec.
Actually, take a
On Jan 24, 2005, at 5:12 PM, Joe Gregorio wrote:
It's good work but it belongs in a primer or best practices document.
+1. I like it, I'd like to use it somewhere, but I don't think it
belongs in the core spec. -Tim
On Jan 24, 2005, at 5:18 PM, Joe Gregorio wrote:
+1
Should there be a suggested size for images?
A suggested aspect ratio, actually. Drat. Brent Simmons loved this
idea, and I meant to update the draft. Would anyone be upset if I
updated the draft to say an aspect ratio of 2 (horizontal) to
On Jan 24, 2005, at 5:45 PM, Graham wrote:
1. Is there a deadline for new feature proposals? Has it passed?
There's one I want to make that depends on whether or not one in the
current round is accepted.
This being an IETF WG, you can always post a comment to a draft. If
rough consensus
On Jan 15, 2005, at 10:47 AM, David Powell wrote:
I've just updated this proposal thanks to some of the feedback that I
received. There is a change history at the end of the document.
I'm OK with this. Also OK without it, but I gather that it would
improve some people's comfort levels. Anyone
On Jan 15, 2005, at 1:05 AM, Danny Ayers wrote:
Seems to me like making a source-URI reference a SHOULD would help
solve an immediate problem, irrespective of the hypothetical problem
of copying.
I see no downside. There are going to be scenarios where it's not
reliable, but there are going to
This one shouldn't, in my opinion, be on our active-discussion queue,
because it's uncooked. That is to say, it doesn't actually propose
specific changes to our format or protocol drafts.
Having said that, the thinking seems usefully clean and minimal, and I
wouldn't be surprised if a real
-1
I think this issue has been discussed to death and the current
consensus around atom:id and atom:updated will meet users' needs simply
and elegantly. Trying to achieve consensus on a generalized abstract
model of versioning is doomed to failure. -Tim
+1
I wrote it and I still think it's necessary as a bare-minimum measure.
-Tim
On Jan 13, 2005, at 2:29 PM, David Powell wrote:
Does anyone have any example use cases for mustUnderstand?
1. A stream of financial disclosures from a public company in a
highly-regulated industry. The legislation is very clear that they may
not say anything in public unaccompanied by
On Jan 12, 2005, at 8:57 AM, Robert Sayre wrote:
Or, for that matter, different titles and URIs. I think we should drop
the restriction.
Any time you drop a restriction, you're adding complexity to
implementations. Might be worthwhile, but should be born in mind. -Tim
On Jan 12, 2005, at 3:25 PM, Antone Roundy wrote:
http://www.intertwingly.net/wiki/pie/PaceMustUnderstandElement
Any Atom document MAY contain a single atom:must-understand element,
which, if it appears, MUST be the first child element of the document
element.
I think we need to add language
On Jan 8, 2005, at 8:23 AM, Bill de hÓra wrote:
My answer to this question is that Atom doesn't have a model in terms
of being able to talk about extension so there's no point discussing
it. Extensibility is probably out of scope for the format.
I'm not going to let that go unchallenged. The
On Jan 7, 2005, at 2:38 PM, David Powell wrote:
I think if we ensure that these properties apply to the Atom model,
then it will be beneficial to Atom, and will make any mapping between
Atom and RDF a lot simpler.
Please propose specific edits to current drafts for the WG's
consideration. -Tim
On Jan 4, 2005, at 1:39 AM, Henry Story wrote:
I was just looking closely at the atom:Person class [1] and found some
pretty arbitrary limitations:
- why should a Person only have one e-mail address?
- why should a Person only have one associated url?
It does seem to me that this will make
I'd sent an initial draft to Paul Sam, but then forgot to follow up.
These are notes that represent my personal take-aways and are obviously
not binding on anybody.
1. We need another face-to-face at which some of the big
201 - 253 of 253 matches
Mail list logo
