might need to be
updated to the Freed/Klensin draft that the format references.
Robert Sayre
outlining the compromise?
Robert Sayre
So, if accepted, we'd have 2 conflicting rules. The Pace needs an edit)
D'oh. You're right. I've edited the Pace, to just delete the MUST.
Robert Sayre
== Abstract ==
Remove the requirement for a feed-level link element.
== Status ==
Open
== Rationale ==
The requirement makes people jump through hoops for little gain, since
there is a strong incentive to provide the link if you have something.
Unlike entries, feeds are almost always
of uniqueness.
OK, that's fine with me. There is no required source language,
though. Someone should write a Pace.
This WG has, shall we say, more active management than most. I'm
afraid I can't just write down what I think you mean.
Robert Sayre
and content optional by
striking one line from the spec, to assert that the WG wanted to make
summaries optional.
This is so over, I can't believe it. I cannot believe we are
entertaining this tripe.
Robert Sayre
On 4/28/05, Sam Ruby [EMAIL PROTECTED] wrote:
Robert: why did you ask for an example?
To find out about any technical issues, not to hear Roger repeat himself.
Robert Sayre
to do would be
to refer the question to Mark Nottingham. I've begun training an email
filter to forward questions to him ;)
That is not a problem worth creating in return for advocating the type
of feed we think is cool right now.
Robert Sayre
I'm obviously very down on normative language requiring a summary. I
am open to non-normative language explaining the syndication medium as
we see it today. I acknowledge that people who don't know what they're
doing sometimes create unhappy users by providing title-only feeds.
The examples,
atom:source more explicitly. Is there anything else we can do
that would license the validator to flag the Yahoo feed in Sam's post,
but give PubSub et al. a little more room to breath?
Robert Sayre
is precisely akin to specifications that
require alt attributes for img tags. It atom's case, it is a summary.
I've edited Tim's Pace to show what the resulting text would look
like, since a summary would still be required in such circumstances.
Hopefully, the resulting requirements are clear now.
Robert
adequate for some class of applications, so please
demonstrate the interoperability problems they cause.
Robert Sayre
.
This is totally an interoperability issue.
Nonsense. None of Atom's elements communicate that information, and
there is no requirement to do so. Next.
Robert Sayre
. It's overkill,
and pointless. The juice in Atom is in the handling of content...
providing for explicit summaries, and clearly defined payload types.
The juice in Atom has little to do with the syndication format. IDs
and dates are big, though.
Robert Sayre
case: the case where the content is empty.
Nonsense. Never. There are plenty of people here disagreeing with you.
Robert Sayre
making up requirements to add to
the spec. This is over and its a waste of the WG's time.
Let me summarize:
MUST: Sam
SHOULD: Graham, Roger
Eh: Bill
MAY: Myself, James T, Antone, Eric, Julian, Martin, Aristotle
Robert Sayre
Graham wrote:
Can you post some links to examples of feeds you think are difficult to
express in the current syntax? That would be considerably more
constructive than whatever the hell that was.
I've done that before. Go read the archives.
well. I fully agree that's a common occurrence,
but it results in unhappy users who complain to the publisher, not
broken or buggy clients. On the other end of the spectrum, advanced,
site-to-site, or bandwidth-constrained users frequently produce
title-only feeds.
Robert Sayre
implementations can't supply them and
which aren't absolutely needed for interoperability.
This Pace addresses my concerns in full.
Robert Sayre
of
element order, as far as Atom is concerned.
Robert Sayre
What would be necessary to get this feed to render on one HTML page, ala
Bloglines?
http://www.franklinmint.fm/2005/04/21/xmlbase.atom
Robert Sayre
of relative URI references in xlink:href
attribute.
I suppose the case could be made that we're defining our own little
language here, so we are within our rights. Not a very interesting
question, because xml:base seems to create problems for aggregated HTML
displays. A huge bug, IMHO.
Robert
Phil Ringnalda wrote:
Robert Sayre wrote:
What would be necessary to get this feed to render on one HTML page,
ala Bloglines?
http://www.franklinmint.fm/2005/04/21/xmlbase.atom
Running it through a competant Atom processor?
http://feedparser.org/docs/resolving-relative-links.html
That's cool
. Maybe 'use absolute URIs for
maximum data integrity', but I suppose that is always true.
Robert Sayre
we could also use a quick survey of xml:base support in parsers,
xslt implementations, etc. if we don't already have one. xml:base was
supposed to be in XSLT 1.1, and Saxon supports it right now.
Robert Sayre
Henri Sivonen wrote:
Could you also set the MIME type to application/vnd.relax-ng.rnc instead
of text/plain?
Hmm. That's not a registered type, is it?
Robert Sayre
at the documents here:
http://groups-beta.google.com/group/bloggerDev/browse_thread/thread/af9033f3a3f4c7fe/c8e1f7e045d346c9#c8e1f7e045d346c9
-1 to the Pace, BTW. Graham's covered the reasons.
Robert Sayre
to help
your case.
BTW, Graham's suggestion sounds reasonable.
Robert Sayre
Henri Sivonen wrote:
Is the Relax NG schema from the appendix hosted as a standalone HTTP
resource somewhere on atompub.org ?
Now it is.
http://atompub.org/2005/04/18/atom.rnc
Robert Sayre
Norman Walsh wrote:
The point is that extensions should allow atom:content inside the
extension, is that right?
Yes. Any atom element should be allowed in an extension.
Robert Sayre
Graham wrote:
On 17 Apr 2005, at 12:02 am, A. Pagaltzis wrote:
* Robert Sayre [EMAIL PROTECTED] [2005-04-16 21:45]:
Atom Processors MAY display it using normal text rendering
techniques such as proportional fonts, white-space collapsing,
and justification.
MAY or MAY NOT. There's no right answer
Norman Walsh wrote:
/ Robert Sayre [EMAIL PROTECTED] was heard to say:
| Norman Walsh wrote:
|
| The point is that extensions should allow atom:content inside the
| extension, is that right?
|
| Yes. Any atom element should be allowed in an extension.
Fix appended.
Thank you.
And I happened
elements was that (almost)
anything goes.
Sounds right to me. If I'm not mistaken, we'll need to define
'anyElement' in the RNC as follows:
anyElement =
element * {
(attribute * { text }
| text
| anyElement)*
}
Robert Sayre
?
In particular, that's a should against text/plain and text/html in @src.
Robert Sayre
, white-space collapsing, and justification.
MAY or MAY NOT. There's no right answer in there right now.
Robert Sayre
in the RFC? There's normative BNF in various IETF RFCs and
I don't see much difference, especially since RNC looks like BNF and
it's now an ISO standard.
There's no procedural reason, it was a working group decision.
Robert Sayre
of XHTML that allows xh:p/ where xh is bound to the
XHTML namespace URI.
Robert Sayre
/14/prefixed.xhtml
Robert Sayre
Anne van Kesteren wrote:
I don't really like this point of view. This is exactly what creates
interoperability problems and people will blame Atom in the end for
promising to solve problems it does not.
Atom promised to solve HTML interop issues?
Robert Sayre
]-- !--[endif]--o:p/
/p p class=MsoNormalSo, now all the problems are over, how is
the 2405FPW?span style= /spanOutstanding!!!br/
!--[if !supportEmptyParas]-- !--[endif]--br/
/div
/summary
What do we have to say about this?
Robert Sayre
Asbjørn Ulsberg wrote:
On Wed, 13 Apr 2005 23:42:29 +0200, Robert Sayre [EMAIL PROTECTED]
wrote:
Real world example:
[snip example]
What do we have to say about this?
As far as I can see, the code is valid XHTML 1.0 Strict (and thus also
both Transitional, Frameset and XHTML 1.1), so I'm
element [XHTML transitional reference], and
SHOULD be suitable for handling as XHTML.
Robert Sayre
, bnf and rnc fragments. If
you require someone to do this, I will do it.
I'm having trouble seeing the benefit here. They might work well in the
HTML version, but I don't think they do in the text version. Could you
show me an example where it would help the text version?
Robert Sayre
Sam Ruby wrote:
Robert Sayre wrote:
I want the to know the precise technical reason for these requirements.
First, I'd like to ask a favor. Please wait 24 hours before replying to
this email.
No.
In your zeal to filibuster on this particular topic,
Filibuster? What am I trying to delay? I've
Walter Underwood wrote:
--On Friday, April 08, 2005 01:33:20 AM -0400 Robert Sayre
[EMAIL PROTECTED] wrote:
Accessibility is a non-starter absent expert opinion or substantially
similar formats. Frankly, the notion that remote content constitutes an
accessibility concern is absurd. Might as well
for these requirements.
No one has given one. We all agree that accessibility is important.
Please don't respond to me by saying that accessibility is important.
Robert Sayre
with PaceFeedIdOrSelf.
I'm not. link @rel=self is just horrible, and invention anyway.
I guess the people who want to ditch the alternate will be making their
case in Last Call.
Robert Sayre
Sam Ruby wrote:
Tim Bray wrote:
On Apr 6, 2005, at 8:09 PM, Robert Sayre wrote:
summary/?
No. --Tim
summarySome text./summary
I've incorporated Sam's suggested wording.
Robert Sayre
, OK?
Robert Sayre
that
has launched, we'll figure out an orderly way to set up a discussion on
the Paces from the last week.
OK.
Robert Sayre
can point to an alternate
feed like this
link rel=alternate type=some/feed href=... /
Of course, you can't have two alternates with the same media type...
Robert Sayre
Bob Wyman wrote:
Robert Sayre wrote:
You can point to an alternate feed like this
link rel=alternate type=some/feed href=... /
Of course, you can't have two alternates with the same media type...
Yes, you can point to an alternate. However, all you are doing at
that point is establishing
that means that if one element
is unreliable it uses the others.
Mozilla Thunderbird's approach will be similar when the relevant bugs
are closed.
Robert Sayre
, don't you think?
Robert Sayre
Dan Brickley wrote:
* Robert Sayre [EMAIL PROTECTED] [2005-04-07 17:22-0400]
Sam Ruby wrote:
Whether it is for accessibility, or for general usability, I want to
ensure that every entry has a textual, non-remote component to it.
+1
Yeah, but we can't really legislate that, can we? We
.
Robert Sayre
Tim Bray wrote:
On Apr 5, 2005, at 2:53 PM, Robert Sayre wrote:
Anything to add?
No, I think Rob's got it. Sooner is better.
Who's going to take care of submitting the MIME type registration? A
volunteer would be welcome.
I'm unable to discern any consensus around the cardinality constraints
Sam Ruby wrote:
co-constraints are bad.
Entries without either a summary or content or even a link to where you
can find the data are worse.
Does my Pace allow such a creature?
Robert Sayre
to come to an agreement on that. This
appears to have been a tactical error...
Strawmen are usually tactical errors.
My order of preference:
PaceFeedIdOrAlternate
PaceFeedIdOrSelf
Current Text
PaceCoConstraintsAreBad
no one has spoken up in favor of the current text remains true.
Robert Sayre
Sam Ruby wrote:
An additional observation: neither of the examples in section 1.1
include the summary element. Suggestion: change the content in the
first (minimal) example to summary.
summary/?
Robert Sayre
Tim Bray wrote:
On Apr 6, 2005, at 8:04 PM, Robert Sayre wrote:
This pace dropped the requirement for an alternate link. This pace
dropped the requirement for a summary when content is not present.
Yes, because the WG has *never* voiced an opinion in favor of that
constraint,
You
Robert Sayre wrote:
Scott Hollenbeck wrote:
that all
of the examples given in the document are valid according to the
schema?
Oh, you said *all*. The document fragments haven't been automatically
checked, and I just spotted one mistake. The link element in 4.2.9.2 is
broken.
I'm not sure what
.
Will do.
Scott Hollenbeck wrote w.r.t. the namespace:
Yes, we can do it this way. Just please add some text so that so that IESG
reviewers understand that this is a known issue that we have a plan to
address.
OK, will do.
Robert Sayre
Antone Roundy wrote:
On Monday, April 4, 2005, at 09:43 AM, Robert Sayre wrote:
I can't believe people want to put these out on the open Internet
without an alternate.
It seems to me that the reasons for having alternate links in feeds are
almost entirely based on the context in which feeds
Some other URIs for this I-D:
http://atompub.org/2005/04/04/draft-ietf-atompub-format-07.html
http://atompub.org/2005/04/04/draft-ietf-atompub-format-07-from-6.diff.html
Robert Sayre
[EMAIL PROTECTED] wrote:
A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-atompub
clients, so you better
know what you're doing. OTOH, there have been some persuasive arguments
for making it optional.
If we change it, SHOULD seems like the right way to go: the distinction
between 'SHOULD' and 'MUST' in RFC2119 doesn't apply to stupid
implementors.[0] :)
Robert Sayre
[0] http
is a
reasonable argument; except for we have use-cases, and nobody's shown
that the cost is non-zero. -Tim
I copied Tim's feed to http://franklinmint.fm/2005/04/03/ongoing.rss and
removed the link element. This absence caused Bloglines to behave oddly.
Robert Sayre
. Why do you
think they didn't fix it? For example, they will accurately parse a feed
that sends a unix timestamp instead of an RFC822 date.
Robert Sayre
our levels
based on what we are supposed to be choosing from.
If none of them are MUST, there is no social recourse when tracking down
problems or seeking social understanding. Where did this feed come from?
Who makes alternates? What's this all about?
Robert Sayre
top-level:
ultraliberal/...
where the subtype can be anything MarkP's parser groks.
Robert Sayre
Graham wrote:
On 25 Mar 2005, at 11:41 pm, Robert Sayre wrote:
The content of an atom:id element MUST be created in a way that
assures uniqueness; it is suggested that the atom:id element be
stored along with the associated resource.
persistence = ids must be the same each time the entry
again...
Share Alike. If you alter, transform, or build upon this work, you may
distribute the resulting work only under a license identical to this one.
Are IETF drafts compatible with these terms?
Robert Sayre
Sounds like a plan to me. +1.
Robert Sayre
Graham wrote:
Currently we have this
A Date construct is an element whose content MUST conform to the
date-time BNF rule in [RFC3339]. I.e., the content of this element
matches this regular expression:
[0-9]{8}T[0-9]{2}:[0-9]{2}:[0-9]{2}(\.[0
Henry Story wrote:
Clearly it would be very helpful if there were a machine readable way to
set copyright
policy on entries. Any thoughts on that?
This is not an appropriate time to discuss design changes. Please limit
list traffic to specific editorial suggestions and bug reports.
Robert Sayre
Eric Scheid wrote:
On 25/3/05 10:43 AM, David Powell [EMAIL PROTECTED] wrote:
[Proposal]
In Section 6.4.2, add the sentence:
Structured Extension constructs are language-sensitive.
+1
+1
Robert Sayre
elements of atom:entry and atom:feed are considered metadata
elements, and are described below.
to
Child elements of atom:entry, atom:feed, and Person constructs are
considered metadata elements, and are described below.
Robert Sayre
*anywhere*,
then were do we want them?
I think we want them:
1. In atom:feed metadata
2. In atom:entry metadata
3. In PersonConstructs
I think we want to define their role in those locations.
Robert Sayre
Mark Nottingham wrote:
+1 to the just pick something and ship it position
Indeed. Could it possibly matter less? We have more important things to
talk about.
For web:
Bray, Sayre, Duerst, Brickley
For iri:
de hÓra, Höhrmann
For uri:
Gregorio, van Kesteren
Robert Sayre
://atompub.org/2005/03/12/draft-ietf-atompub-format-06.html#rfc.section.8.1
See the security sections of RFC 2854 and HTML 4.01 for guidance.
(use proper references)
Will do.
Robert Sayre
used to have. Long term,
atom:source is nicer.
Robert Sayre
by this specification.
My personal view was that Person constructs should not define the
meaning of foreign content, but the WG clearly favored it.
Robert Sayre
see
why they wouldn't be able to handle xml:lang on xhtml:div.
+1 -Tim
+1 as well. 90% of developers are going to drop xml:lang on the floor
anyway. The other 10% will get it right if it's on the div wrapper.
Robert Sayre
Graham wrote:
On 16 Mar 2005, at 5:13 pm, Robert Sayre wrote:
Graham wrote:
On 16 Mar 2005, at 1:03 pm, Robert Sayre wrote:
PaceHeadless. The chairs agree that both reads are reasonable, and
are ok with this divergence.
The working group aren't. Revert PaceHeadless immediately.
All
on the surface. Let's get some proposed
wordings. On the other hand if we decide to override the editors and
put atom:head back, this goes away (right?)
Wrong. I'm not sure why you guys think entry/head/author serves a
different purpose than entry/source-feed/author.
Robert Sayre
for the ABNF in atom:link.
Robert Sayre
... stops the spec being apparently self-contradicting.
Excellent suggestion, thanks.
Robert Sayre
their syntax is and use
web in both cases?
Sounds good to me. This doesn't light up some religious war, does it?
Robert Sayre
EDITORIAL:
RFC3987, section 5.1 reads
Applications using IRIs as identity tokens with no relationship to a
protocol MUST use the Simple String Comparison...
Should we call this out?
Robert Sayre
-06.html
TXT
http://ietf.org/internet-drafts/draft-ietf-atompub-format-06.txt
DIFF
http://atompub.org/2005/03/12/draft-ietf-atompub-format-06-from-5.diff.html
Robert Sayre
Graham wrote:
On 16 Mar 2005, at 1:03 pm, Robert Sayre wrote:
PaceHeadless. The chairs agree that both reads are reasonable, and are
ok with this divergence.
The working group aren't. Revert PaceHeadless immediately.
Graham,
I have no desire to contradict the decisions of this WG. I acknowledge
that as well): atomPlainTextConstruct and
atomXHTMLTextConstruct still use uppercased type names (in the collected
RNC)
- the current RNC doesn't check for xhtml:div content below XHTML text
constructs.
These mistakes are mine. I promise to check the schema after every edit
next time.
Robert Sayre
are the options for the format?
As with anything, there will be a big mess, and then the good stuff will
get standardized. I don't see a problem.
Robert Sayre
Graham wrote:
On 23 Feb 2005, at 5:05 am, Robert Sayre wrote:
This is what will carry Flickr annotations, and they do it with Atom
and RDF. They made a few mistakes. One of them centered around the
purpose of atom:id. That means *smart people miss the point*, because
it's a subtly different
a few mistakes. One of them centered around the purpose
of atom:id. That means *smart people miss the point*, because it's a
subtly different than RSS. I think starting the example atom:id with
urn:uuid instead of vemmi://; would help quite a bit.
Robert Sayre
and did it well.
As it stands now, the Atom Publishing Protocol does its core tasks
badly. You might not like WebDAV, but this WG does not exist to rubber
stamp RESTlog.
As I've already mentioned, I'm not interested in arguing about religion.
Robert Sayre
http://www.intertwingly.net/wiki/pie/PaceChangeProtocolCharter
Abstract
--
Require upwards-compatibility with WebDAV.
Status
--
Open
Author
--
Robert Sayre
Rationale
understood at the time that it was irrelevant because WebDAV
compatibility was assumed; was I wrong?
IIRC, the WebDAV text was stripped as part of the chairs' read on
consensus, so the editors did not include it. I don't the answer to your
last question.
Robert Sayre
Joe Gregorio wrote:
On Thu, 17 Feb 2005 12:12:49 -0500, Norman Walsh [EMAIL PROTECTED] wrote:
Any chance we could change those attribute values to text, html,
and xhtml?
+1
+1
Robert Sayre
.
Robert Sayre
[0] http://www.imc.org/atom-syntax/mail-archive/msg06611.html
301 - 400 of 514 matches
Mail list logo
