FYI: Expires Extension Draft
http://www.ietf.org/internet-drafts/draft-snell-atompub-feed-expires-00.txt Example: ... 2005-08-16T12:00:00Z ... or ... 2005-08-16T12:00:00Z 2 ... This is not to be used for caching of Atom documents; nor is it to be used as a mechanism for scheduling updates of local copies of Atom documents. - James
Re: Protocol Action: 'The Atom Syndication Format' to Proposed Standard
Rar! On 17 Aug 2005, at 6:35 pm, Bob Wyman wrote: This is excellent news! Finally, we have an openly and formally defined standard for syndication. Wonderful! bob wyman
RE: Protocol Action: 'The Atom Syndication Format' to Proposed Standard
This is excellent news! Finally, we have an openly and formally defined standard for syndication. Wonderful! bob wyman
Protocol Action: 'The Atom Syndication Format' to Proposed Standard
The IESG has approved the following document: - 'The Atom Syndication Format ' as a Proposed Standard This document is the product of the Atom Publishing Format and Protocol Working Group. The IESG contact persons are Scott Hollenbeck and Ted Hardie. A URL of this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-atompub-format-11.txt Technical Summary: This document describes the Atom format for syndication. It is XML-based and is considered to be the successor to the earlier RSS formats. Its primary use is for web-based content, but is expected to be used for non-web content as well, such as personal news feeds. Working Group Summary: Some members of the working group remain unenthusiastic about some sections of the document, but the chairs strongly believe that there is rough (or better) consensus in support of the document as a whole. For some of the parts with the most contention, there cannot be more than very rough consensus due to basic differences in the way people would design parts of the format, particularly given that we have many models in existence with the different flavors of RSS. For some parts of the document, there is contention about whether or not a particular item should or should not be in the Atom core versus being an extension. For some parts, there is contention whether there should be MUST/SHOULD/MAY leeway for content creators in the presence or absence of an element, or the semantic content of an element; the group really pushed RFC 2119 around during the past few months. Protocol Quality Scott Hollenbeck and the XML Directorate have reviewed the specification for the IESG. Test implementations have confirmed basic protocol soundness.
Re: Feed History -03
On Aug 17, 2005, at 4:10 AM, Henry Story wrote: Yes. I agree the problem also exists for complex extensions. My question is the following: How can a parser that parses atom and unknown extensions, know when to apply the xml base to an extension element automatically? It can't. Anyway to summarise: if you don't want to use the atom:link element then perhaps it would be best to use the xlink:link attributes. I have only read that spec quickly [1] but this would mean that the following That would work. I haven't been following this discussion closely enough to understand why there's resistance to -Tim
Re: Feed History -03
On 17 Aug 2005, at 00:14, Mark Nottingham wrote: On 16/08/2005, at 3:05 PM, Robert Sayre wrote: I suggested writing the next tag like this: http://purl.org/syndication/history/1.0/next"; href="./ archives/archive1.atom"> That's what I would do, too. Not my spec, though. Mainly so I could put a title in that said "Entries from August" or whatever. For that matter, if Henry's interpretation were correct, the element could be ./archives/archive1.atom And Atom processors would magically know that XML Base applies to the URI therein. It's the magic that I object to; inferring the applicability of context based on the presence or absence of other markup isn't good practice, and will lead to practical problems. E.g., what if I want to have an optional attribute on an empty element? Is it "simple" or "complex"? Yes. I agree the problem also exists for complex extensions. My question is the following: How can a parser that parses atom and unknown extensions, know when to apply the xml base to an extension element automatically? Clearly if the extensions themselves were to use only xlink:link elements that would be easy. (though atom itself does not give a good example by not following that principle). Is there a place that parsers can get information where they can automatically tell that an attribute is a xlink:link copycat? Or how do they tell that the content of an element is a URI? Can DTDs or RelaxNG files help? If they could help, would they be retrievable mechanically by a processor of xml to help it work out how to deal with relative references? Anyway to summarise: if you don't want to use the atom:link element then perhaps it would be best to use the xlink:link attributes. I have only read that spec quickly [1] but this would mean that the following would widely be understood to work with the xml:base. Henry Story [1] http://www.w3.org/TR/2001/REC-xlink-20010627/ This interpretation of extensions seems very fragile to me. -- Mark Nottingham http://www.mnot.net/
Re: Feed History -03
Mark Nottingham wrote: > For that matter, if Henry's interpretation were correct, the element > could be > >./archives/archive1.atom > > And Atom processors would magically know that XML Base applies to the > URI therein. It's the magic that I object to; inferring the > applicability of context based on the presence or absence of other > markup isn't good practice, and will lead to practical problems. E.g., > what if I want to have an optional attribute on an empty > element? Is it "simple" or "complex"? FYI, I already rose this up in late May [1]. That was before format-09... [1] http://www.imc.org/atom-syntax/mail-archive/msg15863.html -- Thomas Broyer
