Re: I-D ACTION:draft-nottingham-atompub-feed-history-06.txt
Mark Nottingham wrote: How about: [[[ Archive documents are feed documents that contain less recent entries in the feed. The set of entries contained in an archive document published at a particular URI SHOULD NOT change over time. Likewise, the URI for a particular archive document SHOULD NOT change over time. These stability requirements allow clients to make certain assumptions about archive documents; they may safely assume that if they have retrieved the archive document at a particular URI once, it will not meaningfully change in the future. ]]] they may safely assume - they can safely assume - ie, this boils to a cache directive - any need to specify what one can infer here? You could state there are consequences when servers deviate from SHOULD NOT. But +1, sounds good. cheers Bill
Re: atom:updated - not now() values?
Eric Scheid wrote: When updating an entry, is it acceptable to insert a value other than Now() into atom:updated? Yes. Reasons below. For example: Corporate Communications prep a release and they stamp it with a release date of Monday 4 PM ... but I don't see this release update until I get into the office at 2 PM Tuesday, and thus I quickly enter it into the CMS and set the atom:updated value to Monday 4 PM. That's the kind of scenario that's begging for a business rule. I don't see anything in Atom that disallows those kind of policies. 1: the above scenario has run into the difference between document management, content management and publication. Atom doesn't distinguish between those. 2: an asshole reading of atom:updated says it should bind to the Atom Entry . A moron reading says it could bind to the thing the Entry is trying to describe (a press release, or news about a press release, or...). Atom isn't precise enough in it's denotation to say one way or another. 3: Literally, the spec doesn't say you must enter a Now() value. It also doesn't say whose Now() value you should enter. I think policy you would apply would be primarily driven by what you think atom:updated points at, ie, the first point to close out above is 2. It does not help that Atom says little about Entry life cycles, for example, how Entries get onto servers in the first place, which is the issue your scenario has to deal with. Btw, I think the scenario describes a highly plausible state of affairs. cheers Bill
Re: clarification: escaped
A. Pagaltzis wrote: * Robert Sayre [EMAIL PROTECTED] [2006-07-26 01:45]: On 7/25/06, Bill de hÓra [EMAIL PROTECTED] wrote: And I didn't know whether Atom code could get away with escaping and . atom:title type=htmllt;bnbsp;hmmlt;b/atom:title that is an XML fatal error, no doubt, as the ampersand before nbsp must be escaped. But he did say “escaping and ”, so it would be. I’m not sure what Bill’s question even is. What do I escape, so I know what to unescape? cheers Bill
clarification: escaped
The RFC says that the content should be 'escaped' for type 'text/html' in 3.1.1.2, but dosn't define what that is. Is it as defined in XML: http://www.w3.org/TR/REC-xml/#dt-escape ? cheers Bill
Re: clarification: escaped
Robert Sayre wrote: On 7/25/06, Bill de hÓra [EMAIL PROTECTED] wrote: The RFC says that the content should be 'escaped' for type 'text/html' in 3.1.1.2, but dosn't define what that is. IIRC, WG discussion touched on this point, and the WG decided the definition wasn't important, given the example. Is there a problem you're hoping to clear up? It came up on django irc. I'd assumed for whatever reason that escaping was limited to the usual XML suspects, but when asked about html content I knew I didn't know for sure, especially wrt HTML character entities. And I didn't know whether Atom code could get away with escaping and . cheers Bill
Re: http://www.intertwingly.net/wiki/pie/XhtmlContentDivConformanceTests
James M Snell wrote: Antone, Very good write up. The fact that xml:base on div is not valid XHTML is somewhat irrelevant given that there is an identical problem with xml:lang. For instance, if I have content xml:lang=endiv xml:lang=fr.../div/content and I drop the div silently, then I've got a problem. Granted, the producer of the atom feed really shouldn't have done this, but we still need to be able to handle it properly if it does happen. I don't agree bug compliance is the way to go. If downstream code has to patch against broken providers that's a race to the bottom - it's a culture where specs cease to matter because they can be mercilessly E and E'd. File a bug report instead. Otoh if we have spec'd in a feature here which doesn't sit on top on XML infrastructure properly, that's another matter - hey, xml lib, handle this element special like, cos atom markup don't care about clean layering sounds like a problem. We seem to keep doing that with xml:* features (lang, include, base). Atom is to XML as HTML is to SGML? cheers Bill
Re: I-D ACTION:draft-ietf-atompub-protocol-09.txt
Hi James, I understand what you mean. We'll patch the English on that sentence next time around. cheers Bill James M Snell wrote: Ok, reading it again I think you're right, either way, however, the construction of the sentence looks odd. Shortening it up to use your wording below would likely be better: The response to a POST request containing an Atom Entry Document SHOULD contain a Content-Location header that contains the same character-by-character value as the Location header. - James Sylvain Hellegouarch wrote: James, First minor nit: Section 8.1: When the POST request contains an Atom Entry Document, ... that should read POST response and not POST request I think you make a mistake. POST request is the correct wording here... well it is my understanding. But if you are correct one should read, a response to a POST request not POST response. - Sylvain
Re: Two minor editorial suggestions (Was: I-D ACTION:draft-ietf-atompub-protocol-09.txt)
Andreas Sewe wrote: Well, the subject says it all; here they are: - It were nice if the example in 7.1 would include @xml:lang, since both workspace/@title and collection/@title are Language-Sensitive. Granted, there might be a Content-Language response header (not shown) to do the job, but IMHO the example would benefit from making language information explicit. +1. Which are clients supposed to respect in a conflict, the Content-Language header or the xml:lang, ie, does XML On The Web Failing Miserably, Utterly, And Completely extend to Content-Language+xml:lang? - The proposed file extension for APP Introspection Documents (.atomsrv) and its media type (application/atomserv+xml) are inconsistent. It would IMHO be better to use either atomsrv or atomserv consistently in both file extension and media type. Everything else is just confusing for no good reason. I have no strong prefs here (other than liking application/app+xml). cheers Bill
Re: Two minor editorial suggestions (Was: I-D ACTION:draft-ietf-atompub-protocol-09.txt)
Eric Scheid wrote: On 30/6/06 1:34 AM, Bill de hÓra [EMAIL PROTECTED] wrote: Which are clients supposed to respect in a conflict, the Content-Language header or the xml:lang, ie, does XML On The Web Failing Miserably, Utterly, And Completely extend to Content-Language+xml:lang? xml:lang, if you think of xml being nested. in other words, what is the lang of the atom:content below: HTTP 200 OK Content-Language: ch ... feed xml:lang=fr ... entry xml:lang=it content xml:lang=en ... ... /content ... /entry ... /feed Hi Eric, I guess my next question is - do we need to tell people this in the protocol spec, or should I Just Know That, Utterly, And Completely ? cheers Bill
Re: Model vs Syntax
A. Pagaltzis wrote: By and large, I agree with him that it would have been beneficial to specify Atom just a little more closely at a model level. But I also agree with you that aspiring to much higher rigor beyond the Infoset level is unnecessary. My retrospective opinion is that the correct approach would have been to specify that an Atom Feed Document consists of a series of completely independent Atom Entries, each of which can be interpreted in isolation of any others as well as of the Atom Feed Document that they are found in (modulo Person Construct inheritance). This would explicitly allow consumers to rely on this atomicity (pun intended), thus preventing any extensions from crossing these boundaries. This goes beyond the mere interchange of messages to a definition of a standardised model, though as you can see, it’s a very loose one. I contend it is also the model used implicitly by any useful aggregator which tracks feed content over time. I think this group would not have been able to agree on what a little more was, the current situation makes sense to me. IMO, the Infoset is no basis for a model; it's there for spec writers and marshalling off the wire. cheers Bill
Re: Fyi, Apache project proposal
Sylvain Hellegouarch wrote: Demokritos might be quite well advanced but unfortunately Python code is not very suited for us poor souls who still have to struggle with java environments ;-) I guess I kind of got that as well. That being said, it will be nice of the project at some point can state exactly how it will either support other environments or at least what bridges it will offer to those, because equally to the fact Python is not suited to your needs, Java is not even on my book ;) I definitely don't want to start a language flame but I merely want to understand if that project will concern me on the long run or not. Dude, Rails like totally does all that already. :-) cheers Bill
Re: Last Call: 'Atom Threading Extensions' to Proposed Standard (draft-snell-atompub-feed-thread)
The IESG wrote:
The IESG has received a request from an individual submitter to consider
the
following document:
- 'Atom Threading Extensions '
draft-snell-atompub-feed-thread-10.txt as a Proposed Standard
The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send any comments to the
iesg@ietf.org or ietf@ietf.org mailing lists by 2006-06-12.
The file can be obtained via
http://www.ietf.org/internet-drafts/draft-snell-atompub-feed-thread-10.txt
I'm -0 this becoming a Proposed Standard. I think this is really cool,
has room for interop problems, probably has security issues, and thus is
arguably premature/innovative and could be considered informational.
One reason I think it's cool is not for commenting support but for cheap
full duplex/reliable messaging - traditionally a SOAP use case.
FTR, I have no implementation experience with Feed Thread, haven't
studiously followed the discussion on atom-syntax and that basis feel my
opinion doesn't count for that much.
== Multiple references
thr:in-reply-to
ref=tag:entries.com,2005:1
type=application/xhtml+xml
href=http://www.example.org/entries/1/
In particular the RNC:
in-reply-to =
element thr:in-reply-to {
atomCommonAttributes,
( ref, source?
| href, type?
| ref, source?, href, type? )
}
varies in co-occurrence constraints. No one attribute seems to be
required in all cases, which is a problem imo (if I'm wrong I'll argue I
still have a point that it's unclear what an implementor should look
for). I think this will be an interop headache and that either ref or
href should always be required. Naturally ref to atom:id is to spec the
right choice, but in practice it seems the first thing anyone will want
to do unless they are the authority for the comment *and* the entry is
pull down what's being replied to via href. Otoh, mandating ref implies
as yet undeployed/unstandardised lookup/query services for atom:id - we
have enough experience now with identity lookup services
(CORBA/Agents/JNDI/UDDI/SPARQL) to suggest that this kind of service
won't ever be deployed uniformly, or will be deployed in a way that
isn't some kind of SPOF or business model or outright failure. That, or
the feature will end being limited to local cases where ref is preferred
over href (point to point integrations come to mind, hence the mention
of SOAP).
This of course is fallout from the way identity in Atom is specced,
which is also a hedge. Feed Thread imvho should consider getting off the
fence on id v link and providing guidance for follow on extensions.
== @rel optionality
[[[
allow Atom clients that are not familiar with the in-reply-to
extension to know that a relationship exists between the entry and
the resource being responded to, publishers are advised to consider
including a related link referencing a representation of the
resource identified by the in-reply-to element.
]]]
I think to do anything useful with this relation you would have had
enough code written to switch on thr:in-reply-to to begin with. It could
be struck.
== Interop
There are multiple publishing options in terms of how to associate
comments with entries/comments. That this hasn't bitten anyone yet seems
to me to be a combination/result of lack of implementations targeting
the feature, Atom's mU policy for extensions, and (possibly) a lack of
experience with comment aggregation across publishing and aggregating
authorities.
Do the WG believe this will work out with multiple authorities using
multiple stacks?
== Security
[[[
As this specification defines an extension to the Atom Syndication
Format, it is subject to the same security considerations as defined
in [RFC4287].
]]]
I have a serious enough quibble with this statement (the ddos attack
note notwithstanding). As an atom foreign markup extension, it's true on
the face of things, but the thr:reply-to semantics introduce
attribution/repudiation issues as well as providing aggregator/planet
spamming options. IOW thr:in-reply-to seems to standardise the same
attack/spam vectors we see in mail for feeds and this needs to be
acknowledged given spam mail is a multi-billion dollar sinkhole (or
industry depending on the pov). That's a dramatic way to state things
sure, but not without some truth. So - where's the digest/sig hook?
James, you know this stuff... :)
cheers
Bill
addition to next rev of FH?[was Tools that make use of previous/next/first/last links?]
(ot for the last thread) Hi Mark, I've just specced out an app that uses FH and this idea of an archived feed hadn't quite come across to me as safe - I had some what ifs about server resets that affected the feed. However, the URL: http://example.com/feed?start=5num=10 nails that concern for me and thus your point about chunky URLs which dynamically generated feeds rings true. Would you consider calling this out thing directly in a future rev? I think it might be helpful for robust server designs if some guidance were given. cheers Bill Mark Nottingham wrote: If you use URIs like http://example.com/feed?start=5num=10 changing the directionality of next and previous will not make what you're doing compatible with feed history. Such URIs have a much more fundamental problem -- they don't refer to a stable set of entries, and therefore only act as a snapshot of the *current* feed, chopped up into chunks. If the feed changes between accesses, the client will be in an inconsistent state. The client also has to walk through all of the pages every time it fetches the feed; it can't cache them -- which is a primary requirement for feed history. What are the requirements that drove you to this type of paging solution? On 2006/05/02, at 9:14 PM, James M Snell wrote: Mark Nottingham wrote: [snip] As it stands now, a single feed cannot implement APP, OpenSearch AND Feed History. Please describe the scenario where you'd want that to happen -- show the feed. The feed(s) are part of our open activities implementation and are available via our APP interop endpoint [1]. Our APP collection feeds are also the feeds people subscribe to and search with (e.g. any of our feeds accept querystring parameters to filter the feed results). Requesters can set the page size as a querystring, if the result set is larger than the page size, the feed is automatically paged using first/last/next/previous. The fact that our entries are sorted in reverse chronological order makes us compliant with APP, but makes it impossible for clients to use the Feed History algorithm (current has a next but no previous). - James [1] http://www.imc.org/atom-protocol/mail-archive/msg04795.html -- Mark Nottingham http://www.mnot.net/
Re: Reader 'updated' semantics
Tim Bray wrote: On Jan 10, 2006, at 9:07 AM, James M Snell wrote: In RSS there is definite confusion on what constitutes an update. In Atom it is very clear. If updated changes, the item has been updated. No controversy at all. Indeed. There's a word for behavior of RssBandit and Sage: WRONG. Atom provides a 100% unambiguous way to say this is the same entry, but it's been changed and the publisher thinks the change is significant. Software that chooses to hide this fact from users is broken - arguably dangerous to those who depend on receiving timely and accurate information - and should not be used. -Tim I agree with this, up to the point that flipping the updated bit becomes a spam vector. cheers Bill
Re: Category URI's
Graham Parks wrote: On 9 Jan 2006, at 9:33 pm, A. Pagaltzis wrote: category scheme=http://.../tag; term=?tag=foo label=foo / category term=http://example.org/cat/foo; label=foo / cheers Bill
Re: app:updated ordering in Collections
Joe Gregorio wrote: The latest draft is -06 and is available here: http://bitworking.org/projects/atom/atomapi/draft-ietf-atompub-protocol-06.html Hi Manuzhai, try this one: http://bitworking.org/projects/atom/draft-ietf-atompub-protocol-06.html cheers Bill
Re: What is this entry about?
Antone Roundy wrote: On Oct 21, 2005, at 5:47 PM, James M Snell wrote: Err, are you forgetting atom:category? Doesn’t that satisfy all your wants *and* more? It has a URI, a term and a human-readable label. Regards, I dunno, that's why I was asking ;-) atom:category works well for categorizing entries, but does it really tell us what the entry is about? For instance, suppose that I want to indicate that an entry is about http://www.ibm.com and file that in a category called technology? The categorization of the entry is different than the subject of the entry.. tho both are definitely related. Why don't we define link/@rel=about for pointing to a specific internet resource that an entry is about (a little more specific than the general case of rel=related). I know we discussed this before and in the chaos of trying to hammer the spec out, didn't do it, but I still think it's a good idea. -1 to about. The proposal here is saying the feed is subject to the link not that the link is the object of the feed. About can mean either. cheers Bill
Re: Profile links
James M Snell wrote:
Bill de hÓra wrote:
I think you're proposing to enable a kind of Atom microformat - if you
see profile ?x check for ?a ?b and ?c. Sorting it out on consumer
sounds flaky ('sounds', not 'is'), but this also might be very cool. I
wonder why you need a link to do this instead of foo:profile tag.
Precisely. Yes, sorting everything out on the client does *sound*
flaky, but we're not introducing any new problem here. XHTML
microformats have the same problem.
Microformats for the most part have a defined structure; this proposal
isn't providing structure.
Regarding the use of a link versus foo:profile, I really have no
preference one way or the other. The profile reference should be a
dereferencable link to a profile document that describes the profile
but, for the most part, clients will likely only rarely ever dereference
it (using the href more as an identifier). Strictly speaking,
dereferenceable profile links should probably use the atom:link element
but there is no hard requirement that says a profile element wouldn't
also work.
Using atom:link strikes me as tag abuse [1]. But that's what
microformats tend to do (use presentational markup for data).
cheers
Bill
[1] http://www.ucc.ie/sdata/faq.html#whatis
Re: What is this entry about?
James M Snell wrote: Bill de hÓra wrote: For instance, suppose that I want to indicate that an entry is about http://www.ibm.com and file that in a category called technology? The categorization of the entry is different than the subject of the entry.. tho both are definitely related. There are two distinct forms of discourse going on here - This entry is talking about some subject area or entity or resource. It says something about something else. Being able to do this pretty much why RDF was invented. - This entry is classifiable under some subject area or topic or class. It has something has sense of belonging or association to something else. Being able to do this is pretty much why Topic Maps were invented. Please, please, please, do not conflate these. Oh absolutely, I'm not trying to conflate 'em. I want to find a solution to the first case (this entry is talking about some subject area) that preferably does not involve invention or abuse of existing formats/tags. I'm more than aware that RDF does this already but I not sure how that fact helps us in Atom (which is not RDF). [RDF and TM were exemplary; cc'd to Henry/Danny] Ah ok; I had read the proposal initially as subject classification (dc:subject had me thinking that way). If you're looking for a way to say this is entry is saying stuff about something over there, then dc:subject and atom:category aren't a good fit as they're more or less pointing the wrong way. rdf:about is the closest analog in semweb land (plus it takes urls), but it's the wrong thing here (I'll get to this). You could do any of the following: - define an atom:about tag or attribute that takes a URL. - use a @rel=about on a link tag You can't use an rdf:about on the atom:entry element for this and that's to do with entry metadata associations. What we want to say is that the entry to talking about something else. With rdf:about the entry *metadata* will become bound to the something else and not the entry (which is messed up). The only sensible way I see is to work in terms of the entry URI and the URI you're pointing at: 'entryURI isabout someOtherURI' and define a new term for this purpose. Anyone that wants to model this formally has enough information in the entry markup to consistently generate the correct RDF statements out of band. [I'm not suggesting RDF stuff for this - it's just very useful for teasing out issues] cheers Bill
Re: Profile links
James M Snell wrote: Bill de hÓra wrote: Microformats for the most part have a defined structure; this proposal isn't providing structure. For the most part yes. Regarding the use of a link versus foo:profile, I really have no preference one way or the other. The profile reference should be a dereferencable link to a profile document that describes the profile but, for the most part, clients will likely only rarely ever dereference it (using the href more as an identifier). Strictly speaking, dereferenceable profile links should probably use the atom:link element but there is no hard requirement that says a profile element wouldn't also work. Using atom:link strikes me as tag abuse [1]. But that's what microformats tend to do (use presentational markup for data). Agreed. So what's a better solution? Like I said, I really have no preference one way or the other. (taking off my markup hat) If someone said to me you can check an entry's profile via an atom:link/@rel='profile' I would say 'ok, that's fine' (soon followed by 'what should I do if all the other metadata isn't there?'). If it's truly abuse the registrar can trap it and tell you to use something else. The reason to pick a dedicated element instead is if the WG wants to set a precedent on how the format is to be extended (we have multiple points of extension and no guidance as to how to choose between them). Otherwise I think atom:link will be ok. cheers Bill
Re: Profile links
James M Snell wrote: James Holderness wrote: James M Snell wrote: Hmm.. the more I think about this and the more we discuss it, the less I think I like link[rel=profile]. While the URI of the profile reference should be dereferenceable, most of the time the profile value is going to be used as an identifier. entry x:profilehttp://example.com/profiles/weblog/x:profile x:profilehttp://example.com/profiles/podcast/x:profile /entry I agree about not using link, but shouldn't the URI be in an attribute rather than as content. Something like this: entry x:profile href=http://example.com/profiles/weblog/ x:profile href=http://example.com/profiles/podcast/ /entry Works for me. 'href's can traditionally be dereferenced, no big deal - the upside is the markup structure does gives you scope to extend later. 'ref' - ? cheers Bill
Re: What is this entry about?
James M Snell wrote: Ok, so thus far: we can indicate resources that are related to the given entry; we can indicate that an entry is a reply to another entry; we can specify categories to which the entry belongs; but there is currently no way of indicating the *subject* of the entry. The best options appear to be: a. Use dc:subject (appears to be a perfectly acceptable solution to me assuming that the subject indication is intended for human consumption entry dc:subjectThe Atom Specification/dc:subject /entry or... b. Use link[rel=subject] (which works if the subject is identified/described by a dereferenceable URI) entry link rel=subject href=http://www.ietf.org/internet-drafts/draft-ietf-atompub-format-11.txt; / /entry I think either approach works. The dc:subject approach is ambiguous. The link approach requires invention. The link approach doesn't seem to be less ambiguous than dc:subject. For lessened ambiguity you might want to use published subject indicators a la topic maps. cheers Bill
Re: What is this entry about?
James M Snell wrote: Bill de hÓra wrote: The link approach doesn't seem to be less ambiguous than dc:subject. For lessened ambiguity you might want to use published subject indicators a la topic maps. It is less ambiguous in that a URI is less ambiguous that some arbitrary text string. Further, the link approach is perfectly compatible with the published subject indicators a la topic maps approach. There's no requirement to use an arbitrary text string in dc:subject*. And even then, I have no idea how a URL (you did say these things had to be dereferenced) is less ambiguous than a string - they're equally arbitrary unless we're talking about their use in something like OWL. The link approach still doesn't seem to be less ambiguous than dc:subject, ie it does not seem to be a basis for choosing one over the other. cheers Bill * The dc:subject value is recommended to be taken from some controlled set. The @rel=subject idea doesn't say anything about the link being a PSI. The link approach is perfectly compatable then with PSIs insofar as you would have some other interpretation that lookups the URIs and sees if they're actually PSIs, or not.
Re: Profile links
James M Snell wrote:
Another subject that has come up in recent discussions is an extension
that can be used to specify the purpose of a feed. For example, is the
feed an archive, is it a podcast, is it used for discovering web
services or publishing blog content, etc.
The approach that I have in mind is to use link[rel=profile] where the
href points to a profile document of some sort.
For example,
feed
...
entry
link rel=profile href=http://example.com/profiles/podcast; /
link rel=profile href=http://example.com/profiles/weblog; /
...
/entry
/feed
The profile documents could be anything really, but generally describe
the kinds of metadata and content that the entry is expected to
contain. For instance, the podcast profile could indicate that the
entry should contain at least one link[rel=enclosure].
Any single entry may contain multiple profile links. It is up to the
feed consumer to make sense of it all. If an entry specifies
contradictory profiles, it's up to the consumer to sort it out.
The profile documents should be dereferenceable.
Thoughts? Gripes? Praise?
I think you're proposing to enable a kind of Atom microformat - if you
see profile ?x check for ?a ?b and ?c. Sorting it out on consumer
sounds flaky ('sounds', not 'is'), but this also might be very cool. I
wonder why you need a link to do this instead of foo:profile tag.
cheers
Bill
Re: Feed History / Protocol overlap
Eric Scheid wrote: On 19/10/05 10:58 AM, Robert Sayre [EMAIL PROTECTED] wrote: I already have code that uses next for this. Why do we want to change it? Why did you choose next? Because that is what's already been deployed and what my software uses. -1. Someone else made a poor choice*, you copied that, it's confusing, why enshrine it into official specs? Why not take this opportunity to make a better choice? I looked at Pilgrim's atom feed document for March 2004 ... it said the next document was February 2004 and the previous document was April 2004. Try explaining to anyone that isn't writing an aggregator why that makes sense. No matter which direction you head in, no matter which way the chain is sorted, the next document is always next, so that's not a useful distinction IMHO. You said that to me about next and previous for app:collection when I reuested the value 'next' be changed to 'previous' to be consistent with the notion of elements existing earlier in time. What's different here? cheers Bill
Re: Atom 1.0 ootb with MT3.2
Bill de hÓra wrote: [[[ line 7, column 141: service.post is not a valid link relationship ... eblog/blog_id=3 title=Bill de hÓra / line 15, column 163: service.edit is not a valid link relationship (15 occurrences) ... id=1688 title=XML Virtual Machines / line 157, column 33: Two entries with the same value for atom:updated (9 occurrences) updated2005-09-09T10:56:08Z/updated ^ line 300, column 305: summary should not contain HTML unless declared in the type attribute (2 occurrences) ... http://example.com/person/elvis;...]]/summary ]]] Resolutions: service.edit/service.post: MT seems to be working off draft-ietf-atompub-protocol-03. Not sure what to do about those, other than remove them. The date issue can be ignored; I recently had to regenerate my feeds. The summary with HTML I intend to fix by placing an @type attribute on the template that will apply to all summaries (since MT has no logic to check). cheers Bill
Atom 1.0 ootb with MT3.2
Here's the feedvalidator results for my journal served up as Atom1.0 as per MT3.2's Atom1.0 template http://feedvalidator.org/check.cgi?url=http%3A%2F%2Fwww.dehora.net%2Fjournal%2Fatom.xml I also see it uses tag: uris as the atom:id value. I think I'll change the template to use the http: URI generated by MT3.2 for the individual entries instead of the tag: (what the rest of the world calls permalinks). I haven't tried to import/export to see if the atom:id is preserved across installations. Speaking of URIs and IDs, there is a gotcha around archive URIs if you are upgrading to MT 3.2 [1]. cheers Bill [1] http://www.dehora.net/journal/2005/09/did_you_know_that_mt32_clips_the_basename_to_30_chars_by_default_and_if_youre_not_careful_an_import_will_trash_your_permalinks.html
Re: Atom 1.0 ootb with MT3.2
Tim Bray wrote: On Sep 9, 2005, at 5:03 AM, Bill de hÓra wrote: Here's the feedvalidator results for my journal served up as Atom1.0 as per MT3.2's Atom1.0 template http://feedvalidator.org/check.cgi?url=http%3A%2F%2Fwww.dehora.net% 2Fjournal%2Fatom.xml I'm getting a 404 on that (or rather the feedValidator is) -Tim Yeah, sorry. I have a ticket in to transfer the domain, but wasn't expecting anything to happen until next week (who'da thunk anything to do with DNS could happen on the same working day). cheers Bill
Re: If you want Fat Pings just use Atom!
Tim Bray wrote: On Aug 22, 2005, at 7:26 AM, Joe Gregorio wrote: Essentially, LiveJournal is making this data available to anybody who wishes to access it, without any need to register or to invent a unique API. Ahh, I had thought this was a more dedicated ping traffic stream. The never ending Atom document makes much more sense now. It's got another advantage. You connect and ask for the feed. You get feed xmlns=http://www.w3.org/2005/Atom; ... goes on forever and none of the entry documents need to redeclare the Atom namespace, which saves quite a few bytes after the first hundred thousand or so entries. -Tim Any value in using this to exercise the PaceBatch? If it dealt with the use-case in terms of bulk transfer that would make it more compelling imo. cheers Bill
Re: If you want Fat Pings just use Atom!
Bob Wyman wrote: Aristotle Pagaltzis wrote: I wonder how you would make sure that the document is well-formed. Since the stream never actually ends and there is no way for a client to signal an intent to close the connection, the feed at the top would never actually be accompanied by a /feed at the bottom. This is a problem which has become well understood in the use and implementation of the XMPP/Jabber protocols which are based on streaming XML. It is: every XMPP server has a hack to deal with it ;) Basically, what you do is consider the open tag to have a virtual closure and use it primarily as a carrier of stream metadata. In XMPP terminology, your code works at picking stanzas out of the stream that can be parsed successfully or unsuccessfully on their own. In an Atom stream, the processor would consider each atom:entry to be a parseable atomic unit. How XMPP does that opening stanza thing and then proceeds to not close it is not a design to be emulated (imvho). The opening stanza should arrived and be closed. If you accept that the stream can never be a complete well-formed document, is there any reason not to simply send a stream of concatenated Atom Entry Documents? That would seem like the absolute simplest solution. You could certainly do that, however, you will inevitably want to pass across some stream oriented metadata and you'll eventually realize that much of it is stuff that you can map into an Atom Feed. (i.e. created date, unique stream id, stream title, etc.). Since we're all in the process of learning how to deal with atom:feed elements anyway, why not just reuse what we've got instead of inventing something new. In the Atom case, I don't see why you need to keep the atom:feed open. Just send it once and then send entries in the raw. A rather nice side effect of forming the stream as an atom feed is the simple fact that a log of the stream can be written to disk as a well-formed Atom file. Thus, the same tools that you usually use to parse Atom files can be used to parse the log of the stream. It is nice to be able to reuse tools in this way... (Note: At PubSub, the atom files that we serve to people are, in essence, just slightly stripped logs of the proto-Atom over XMPP streams that they would have received if they had been listening with that protocol. In our clients we can use the same parser for the stream as we do for atom files. It works out nicely and elegantly.) For high load scenarios using Atom/XMPP to decouple the atom processing from xmpp stream handling you can use the log you're talking about as a poor-man's message queue. cheers Bill
Re: Extensions at the feed level (Was: Re: geolocation in atom:author?)
James M Snell wrote: Bob Wyman wrote: Aristotle Pagaltzis wrote: That issue is inheritance. Let me give an example of problematic inheritance... Some have suggested that there be a License that you can associate with Atom feeds and entries. However, scoping becomes very important in this case because of some peculiarities of the legal system. One can copyright an individual thing and one can copyright a collection of things. A claim of copyright in a collection is not, however, necessarily a claim of copyright over the elements of the collection. Similarly, a claim of copyright over an element of the collection doesn't reduce any claim of copyright in the collection itself. If we assume inheritance from feed elements, then without further specification, it isn't possible to claim copyright in the collection that is the feed without claiming copyright in its individual parts. What you'd have to do is create two distinct types of claim (one for collection and one for item. That's messy.) I'm sure that copyright and licenses aren't the only problematic contexts here. bob wyman From the format text: If an atom:entry element does not contain atom:author elements, then the atom:author elements of the contained atom:source element are considered to apply. In an Atom Feed Document, the atom:author elements of the containing atom:feed element are considered to apply to the entry if there are no atom:author elements in the locations described above. This really does not describe an inheritance model*. This describes a scoping model. If an entry does not contain an author, the author on the feed is said to apply. scope v inheritance: call what you like, it's still undefined. 1. We didn't do that, I imagine because it was 'simpler' to say nothing than introduce formalism. The only person that has tried to formally define the relationship is Henry afaik. Unless we have defined clearly the semantics of the relationship between a feed and a entry*, we're hosed if we start trying to figure out the logical implications of domain and range of metadata - whatever we conclude, unless it gets baked into a spec as a patch, somebody with running code will be sure to conclude otherwise. Coincidentally I posted a rant about this kind of specification on xml-dev the other day mentioning feed/entry. 2. It's easy to be tricked by the document structure into thinking there is some form of natural scoping mechanism. If Atom looked like this atom:feed atom:feed-metadata-container atom:entries-container atom:entry or atom:feed atom:entries-container atom:[EMAIL PROTECTED]'feed-metadata' atom:entry We probably wouldn't be having this discussion. Second note to self: After thinking about this a bit more, I would also need a way of specifying a null license (e.g. the lack of a license). For instance, what if an entry that does not contain a license is aggregated into a feed that has a license. The original lack-of-license still applies to that entry regardless of what is specified on the feed level. Golly Bob, you're right, this is rather messy ain't it. Hmm... This is not new ground for the WG. We've been through it and my understanding is that feed level metadata does not inherit/cascade/scope over entries. I seem to recall thinking that atom:author percolating down from the feed is essentially broken, but the consensus was it should do that. It's an exception, not a precedent. As we have no processing model for this, my answer to Paul's question is that feed level extensions do not inherit/cascade/scope over entry level ones, irrespective of whether they're foreign or not, and that the best way to think about atom:author is as a frozen accident. [I hope the folks working on the APP are paying attention.] cheers Bill * Tangentially touched upon here: http://www.dehora.net/journal/2004/06/atomrss_relating_entries_and_feeds.html.
Re: If you want Fat Pings just use Atom!
Walter Underwood wrote: The standard trick here is to use a sequence of small docs, separated by ASCII form-feed characters. That character is not legal within an XML document, so it allows the stream to resyncronize on that character. Besides, form-feed actually has almost the right semantics -- start a new page. In XMPP, you can reset on seeing /atom:entry, assuming you don't have atom:feed left hanging. You probably won't need atom:feed there anyway - feeds are very much artefacts of going over HTTP. cheers Bill
Re: If you want Fat Pings just use Atom!
A. Pagaltzis wrote: * Bill de hÓra [EMAIL PROTECTED] [2005-08-22 19:00]: In XMPP, you can reset on seeing /atom:entry, Really? Really. And I've even seen the two test cases below... ![CDATA[ /entry ]] Or maybe ![CDATA[ ![CDATA[ /entry ]] ... which are cute. I forget I didn't have an opening tag, or a buffer for the entry. Oh wait, I do ;) These are probably the only exceptions (I might be missing some, though), but they’re enough to demonstrate that you will need to write a parser, even if only a relatively simple one. You already have an XML parser, that's not the problem; the problem is managing the stream buffer off the wire for a protocol model that has no underlying concept of an octet frame. I've written enough XMPP code to understand why the BEEP/MIME crowd might frown at it - manipulating infosets right on top on sockets make for funky code and isn't my notion of what bits on the wire should be ;) [Incidentally this is a non-problem for APP because we're piggy backing on HTTP octets...] Using a character which is illegal in XML and can never be part of a well-formed document as a separator is a clever way to avoid having to do *any* parsing *whatsoever*. You just scan the stream for the character and start over when you see it, end of story. No need to keep state or look for patterns or anything else. I see all the +1s, but don't understand why reinventing multi-part MIME with formfeeds as a special case for Atom is more attractive that an infinite list of entries whose closing atom:feed tag never arrives. Still, I think this discussion is valuable: it speaks volumes on the use of XML for wire protocols, especially for the single document school of thought. cheers Bill
Re: Finishing up on whitespace in IRIs and dates
Paul Hoffman wrote: Greetings again. I think we have rough consensus on emitting with whitespace around IRIs and dates is an error and we should warn folks that people might emit errors here because this is somewhat subtle. If that is true, I propose that, just before section 3.1 (at the end of the introductory text to Common Atom Constructs) we add: Note that there MUST be no whitespace in a Date construct or in any IRI. Some XML-emitting implementations erroneously insert whitespace around values by default, and such implementations will emit invalid Atom. +1 cheers Bill
Re: spec bug: can we fix for draft-11?
Robert Sayre wrote: I'll also note that this requirement has basically zero value for a desktop aggragator. I have only written three or four Atom parsers, but I think the approach that has the best mix of performance and correctness is one where SAX events are treated as input events for a scanner-like state machine. Leading and trailing whitespace input for these fields should be discarded by a robust scanner, and doing so proposes no risk to compliant feeds, unlike guessing the true meaning of an ampersand in an RSS feed. So, it will be my recommendation to ignore this MUST-level requirement of the Atom spec in any consumer aggregator that I contribute to. I think it might be useful as bozo filter in an Atom protocol server, because the lazy thing for client implementors to do is find a decent serialization library. The lazy thing for publishers to do is concatenate strings in their loosely-typed language of choice. If you're going to recommend ignoring it in practice, why not recommend throwing it out? Why equivocate? cheers Bill
Re: spec bug: can we fix for draft-11?
Robert Sayre wrote: On 8/5/05, Bill de hÓra [EMAIL PROTECTED] wrote: If you're going to recommend ignoring it in practice, why not recommend throwing it out? Why equivocate? You keep saying equivocate, as if there were some hard-to-swallow truth I'm avoiding. I've said it twice; don't take it personally it's not an attack. I'm suggesting saying something vague because the situation is vague, it doesn't matter very much, and I don't consider detailed information oh whitespace in XML feeds to be the Purpose Of Atom. The siutation didn't just happen to be vague, we made it vague, I don't agree it doesn't matter, and if the Atom spec can't get it's story straight on whitespace to the extent one of the editors is going to advise people to ignore a MUST directive that one of the chairs and others believes has strong consensus support from the WG, then I firmly believe that puts detailed information on whitespace on the table. Finally, if there is a Purpose Of Atom I suspect it has something to do with clarity and unambiguity in specification - and this is not it. I'm going to recommend ignoring it to people writing Atom processors with the intent of consuming a wide variety of feeds for consumer usage. My favorite use case is Grandmother Trying To View Pictures Of Her Grandchildren. Am I going to prevent that from happening in order enforce a whitespace rule? Since there are no compliant feeds I'm hurting, it's an easy decision to make. That said, I know from experience that it's very easy to write an Atom Processor that would choke on such whitespace. I would like for those processors to be supported by the spec as compliant, because writing one should not have to be an exercise in Keep-Going-No-Matter-What consumer software in all cases. I don't really care how they are supported (MAY, SHOULD, MUST...), because it doesn't matter. We do need to write something that lets the feed validator warn people about it, but actually trying to enforce a MUST-level requirement here seems like pissing into the wind. I read that as saying we have a broken spec. If there's another way to read it, help me out. This entire thread is like being in a Joseph Heller novel, except its called Catch-32. cheers Bill
Re: spec bug: can we fix for draft-11?
Sam Ruby wrote: A note that Atom processors may consider leading and trailing space as significant in attribute and element values would be enough to alert people to the interoperability issues. But it wouldn't cater for them. That note would need to be a MUST to be effective. Disallowing leading and trailing whitespace in IRI references (including the isegment-nz-nc production), MIME media types, language tags, lengths, addr-spec, and date-time productions would lead to improved interoperability. I'm fine with either. My best guess is that given the choice to either reject a feed or call trim(), people will call trim(). But some clarity either way would be welcome and would need to be presented as a general processing directive, and not just specific to the element we're talking about. cheers Bill
Re: spec bug: can we fix for draft-11?
Paul Hoffman wrote: At 7:37 PM -0400 8/2/05, Robert Sayre wrote: One way of saying this would be Atom Processors MAY ignore leading and trailing whitespace in _. That works for me. Another idea is Atom Processors MAY ignore leading and/or trailing whitespace in elements whose content does not allow leading and/or trailing whitespace, such as IRIs and . I don't understand the benefits of MAY. It sounds like this to me: whitespace is not allowed in certain elements, but you may ignore that directive by trimming the content. cheers Bill
Re: spec bug: can we fix for draft-11?
Tim Bray wrote: I'm strongly -1 on treating this as anything but an error. We may at our discretion make it forgiveable. I really do not understand - it's an error or it's not not. Elsewhere in their replies, Paul and Robert seem to think this is obviously meaningful. Clearly I don't get it because I just see it as equivocation. cheers Bill
Re: spec bug: can we fix for draft-11?
0. The validator isn't the spec. cheers Bill James M Snell wrote: +++1 Joe Gregorio wrote: On 8/4/05, Danny Ayers [EMAIL PROTECTED] wrote: I don't really understand why this should be treated any differently than the numerous other problematic things that could happen if one doesn't take the spec literally. (I'd suggest spec prose trumps RNG grammar, as there's a lot of other stuff not expressable in the grammar). Some sections of this specification are illustrated with fragments of a non-normative RELAX NG Compact schema [RELAX-NG]. However, the text of this specification provides the definition of conformance. A complete schema appears in Appendix B. This is quoted directly from Section 1.3. This whitespace issue is a good illustration of why the schema isn't normative ;) I would vote for leaving the text as is and having the validator give errors on whitespace. We have the same issue with dates and believe they should be flagged likewise, i.e. errors on whitespace. -joe But now the issue has been raised, it does seem reasonable to add a note (assuming the process is ok for that) to the effect that stray whitespace in content is an error. I can't see how it can be desirable to allow it (though am not given to lying in the road). At the application level we're back to Postel again - publishers shouldn't pump this stuff out, but liberal clients may find it useful to trim whitespace from IRI and date fields. But surely that's outside the scope of the format spec itself. Cheers, Danny. -- http://dannyayers.com
Re: spec bug: can we fix for draft-11?
Tim Bray wrote: I'm getting increasingly grumpy and just fail is looking better and better. The current normative text, The element's content MUST be an IRI, is clear and simple and supported by other well-understood normative text, supported by lots of interoperable software, that make the meanings of element, content, and IRI not really open to intelligent dispute. I claim that text enjoyed strong, not rough, consensus support from the WG. So my preferred course of action would be to leave it the way it bloody well is. [...] So for now, I'm -1 on an weakening or removing The element's content MUST be an IRI or analogous text in any other section. I'll stop shouting if I'm in a small minority here. -Tim Fine by me. However, extraneous whitespace will cause compliant software to puke needs to be said, not inferred. I don't believe the text here is as broadly obvious or as well-understood as you suggest. cheers Bill
spec bug: can we fix for draft-11?
Graham wrote: On 2 Aug 2005, at 5:41 am, James Cerra wrote: id http://example.com/ /id idhttp://example.com//id Those are different ids (Processors MUST compare atom:id elements on a character-by-character basis), and the first is just plain invalid. Why on earth would you think otherwise? The design intent of character-by-character cmp as I understood was for the URI contained by the element. I think confusing the element content with the URI is a spec bug. It's unreasonable to expect people to think they're not the same id and this will be a souce of needless problems unless we fix it. cheers Bill
Re: spec bug: can we fix for draft-11?
Graham wrote: On 2 Aug 2005, at 10:07 am, Bill de hÓra wrote: The design intent of character-by-character cmp as I understood was for the URI contained by the element. I think confusing the element content with the URI is a spec bug. From atompub-format-10, 4.2.6: Its content MUST be an IRI That to me is demonstrates a very clear intention of the working group that the content must be exactly equal to the IRI. Changing this to allow whitespace would represent a major technical change to the format. I will figuratively lie down in the road if anyone suggests whitespace should be allowed around any machine-read content (uris, @type, @rel, etc). I don't want to allow whitespace. But this id urn:foo /id is going to happen, is going to cause problems, and working around it does not strike me as being something you can foist entirely onto the spec's end-users. Assuming everything you said above is true, we're responsible for specifying that XML element content that cannot contain leading or trailing whitespace (to be pedantic, a subset of what XML allows). When we say MUST above, we need to be clear on how we're supposed to deal with cases where someone does not follow the spec. For example, being clear whether the the above fragment is illegal or requires pre-processing would be useful. [You capture the essence when you mention machine-readable content. Really, that stuff should go into attributes not element content for exactly these kinds of reasons.] cheers Bill
Re: spec bug: can we fix for draft-11?
Sascha Carlin wrote: Graham said: the format. I will figuratively lie down in the road if anyone suggests whitespace should be allowed around any machine-read content (uris, @type, @rel, etc). +1. Possible whitespace would add general check removal calls to any processor. When you process 100 items, thats not a problem. Staring with 10.000 is begins tu hurt, and will blow it up when you reach 100.000 items. Interesting. 1. What should I do when I see this: id urn:foo /id 2. What should I do when I see this: id urn:foo /id 100,000 times? Again to make it clear: I am not arguing for whitespace in atom:id. I am arguing that whitespace is inevitable in atom:id and I think in that regard the spec is buggy, one way or another. cheers Bill
Re: spec bug: can we fix for draft-11?
Julian Reschke wrote: Graham wrote: On 2 Aug 2005, at 10:07 am, Bill de hÓra wrote: The design intent of character-by-character cmp as I understood was for the URI contained by the element. I think confusing the element content with the URI is a spec bug. From atompub-format-10, 4.2.6: Its content MUST be an IRI That to me is demonstrates a very clear intention of the working group that the content must be exactly equal to the IRI. Changing this to allow whitespace would represent a major technical change to the format. I will figuratively lie down in the road if anyone suggests whitespace should be allowed around any machine-read content (uris, @type, @rel, etc). +1 A potential enhancement would be to explicitly state that whitespace *isÜ significant here (and of course to make the feedvalidator check it). That still leaves things unsaid - significant in what way? What does make the feedvalidator check it entail? And assuming we did this enhancement how does whitespace square with our MUST be an IRI. Somebody please convince me the spec is adequate here; I'm not seeing it. I'm feeling an urge to go through all the elements for any other machine readable tokens living inside element content and filing bugs against the lot of them. Then I'll do the same with APP constructs like 'draft'. cheers Bill
Re: spec bug: can we fix for draft-11?
Sam Ruby wrote: Even if we decide that whitespace is not significant, I do believe that having the feedvalidator issue a warning in such cases is appropriate. +1 cheers Bill
Re: spec bug: can we fix for draft-11?
Robert Sayre wrote: For me, the most disturbing aspect of this debate is that any resolution will provide very, very little interoperability gain. URIs, like XML Elements, cannot begin or end with whitespace. I don't believe it's worth mentioning in the spec, and I think we're off in the weeds. That said, I certainly wouldn't object to any text warning people not to do it, or explicitly mentioning that you have to call the equivalent of String.trim(). I respectfully disagree. After a day's worth of posting, no-one here has been able to present a compelling argument one way or another as to whether atom:id urn:example.org atom:id is illegal and if so, how software should behave in the light of that. Mentioning things like this the why Atom has to exist at all, imvho. cheers Bill
Re: Atom namespace, qname-uri-qname roundtripping
James Cerra wrote: With RDF-compatible data-oriented namespaces, they are often appended with a / or a # or another separator for consistency. If Atom followed this pattern, the above might be: http://www.w3.org/2005/Atom#feed where the namespace URI is: http://www.w3.org/2005/Atom# I think this is a good idea and that the Atom Spec should use a hash mark at the end like that. The spec authors just want to annoy us RDF folks, I think. ;-) Of course it is too late to change. It is too late to change it. In RDF, it's all URIs, not namespaces, not qnames, not something-else, so it doesn't matter if you work to spec. This only comes up when you are trying to roundtrip RDF through RDF/XML (since XML namespaces is such a flaky technology, depending on it leaves you exposed to roundtripping issues). RDF itself doesn't have the notion of a vocabulary that you might want to corden off in a namepace. Arguably, RDF technologies which are baking in 'using prefix as uri' are building on sand. [All of which reinforces my belief that XML Namespaces are broken as designed.] cheers Bill
Re: Atom namespace, qname-uri-qname roundtripping
Graham wrote: Were the RDF folks not smart enough to think of this problem and come up with a better system or a workaround? You should consider digging through the history. The XML folks were the ones who weren't as you put it, 'smart enough' (XML namespaces) and the RDF folks weren't any smarter given they went along with the XML folks anyway (RDF/XML). The ensuing RDF/XML workaround (fragids as punctuation) doesn't work and raises a bunch of other issues related to what # actually identifies on the HTML Web. There's no general case solution to this, it's architectural, which is why it gets kicked up the W3C TAG periodically. cheers Bill
atom buttons
Hi, what are y'all using for Atom buttons? cheers Bill
Re: Atom error pages
James M Snell wrote: In that vein, what would an example error entry response look like? just a simple basic entry with no fancy schmancy extension elements required? - james Something that contains nothing a machine might be able to automatically process or use as a control flag, say like, a response code... ;) cheers Bill
Re: Atom error pages
Graham wrote: It's far too late for this, but how should Atom servers produce/ clients deal with error pages? Feedster regularly changes its search results feed to a single entry Search results temporarily offline feed document (RSS guid http://www.feedster.com/;), and I think served with HTTP status 200. This seems the wrong behavior for so many reasons. What should they be doing in Atom? Serving it with a 503. cheers Bill
Re: Atom error pages
Graham wrote: On 25 Jul 2005, at 10:51 am, Bill de hÓra wrote: It's far too late for this, but how should Atom servers produce/ clients deal with error pages? Feedster regularly changes its search results feed to a single entry Search results temporarily offline feed document (RSS guid http://www.feedster.com/;), and I think served with HTTP status 200. This seems the wrong behavior for so many reasons. What should they be doing in Atom? And what should the client do? Ah. Display the returned entity body + the retry-after header. Or show a default from the client if there's none. cheers Bill
Re: Atom error pages
James M Snell wrote:
HTTP/1.1 5xx Some Error
Content-Type: application/error+xml
Content-Length:
error xmlns=urn:some-namespace
code scheme={URI indicating error code scheme}{scheme defined
error code}/code
summary{human readable summary of the error/summary
action{URI indicating an action taken by the server in response to
the error}/action
{namespaced extension elements}*
/error
What should happen:
- when the http response is 200 and the code in the XML is '503'?
- when the http response is 200 and the code in the XML is 'snafu'?
- when the http response is 400 and the code in the XML is
'java.lang.ClassNotFoundException'?
Putting codes in two places and/or two layers in a response raise
similiar issues to putting methods in two places and/or two layers in a
request. In the general case - what should happen when the http response
is X and the code in the XML is 'Y' - I think is a non-trivial problem.
cheers
Bill
Re: Notes on the latest draft - xml:base
James Cerra wrote: I'd solve it in the same manner that XML namespaces solved the multiple context problem: by providing a default context as well as explicitly named contexts. The default context works the same way as xml:base or the the default xmlns works now. Explicit contexts would work simular to prefixed namespaces (xmlns:prefix). I suggest reconsidering. It's not clear default namespaces solve anything and in the places where they don't solve anything they are hardly likely to be accused of inducing robustness. If the best of two years on the Atom WG and years of working with XML teaches me anything it's this - format defaults are surprisingly tricky to get right. cheers Bill
Re: I-D ACTION:draft-nottingham-atompub-feed-history-01.txt
Mark Nottingham wrote: On 04/07/2005, at 6:18 PM, Thomas Broyer wrote: Really good work! Thanks! Why not using an xs:boolean for fh:stateful? hence allowing values 0, 1, true and false. I did it this way because I'm not a huge XML Schema fan :) At this point, stateful is effectively xs:boolean with a constraint on the lexical space. I'm not against changing it to '1 or true / 0 or false, except that this makes the spec more verbose (but that's a pretty minor concern, properly managed). What do others think (in either direction)? 1. I don't want to have to link to an XSD library in my XML toolchain just to process true/false in an attribute. 2. I don't want to hack some code together to recognize a single XSD primitive just because I don't want to link to an XSD library. cheers Bill
Re: Old application/atom+xml issues
Mark Baker wrote: IMO, it matters not that no spec prescribes the use of this media type for Atom 0.3 feeds. What matters is whether it's in use today, which we seem to agree is the case. This seems an important piece of information that implementors should know, which is my motivation for asking that it be called out in the interoperability considerations section of the template. Something like; Interoperability considerations: Some existing agents and feeds that support the Atom 0.3 specification, make use of this media type despite Atom 0.3 not being compatible with Atom 1.0. In the spirit of that point about 0.3 being served with the media type being an interop issue - what are the behaviors which will lead to interoperation? The above text is only leads one to ask and I should do what here? and doesn't say anything useful about what to do. cheers Bill
Re: Old application/atom+xml issues
Mark Baker wrote: On Mon, Jul 11, 2005 at 09:59:19AM -0400, Sam Ruby wrote: The most we can do is to say that such things are invalid, and to work with the producers to correct this. Sounds good to me. The majority of the existing atom 0.3 feeds are produced by a relatively few producers. I am confident that these producers will convert over quickly. I am also committed to getting the word out quickly that atom 0.3 feeds are not to be considered valid. In particular, I plan to update the feedvalidator to note this as a problem (first as a warning, and later I will change this to an error). Nice. Thanks for your vigilance, Sam. What Mark said. Now, that's the world as it might be outside the spec. There is still proposed spec text, which I suggest is amended as follows: [[[ Interoperability considerations: Some existing agents and feeds that support the Atom 0.3 specification make use of this media type despite Atom 0.3 not being compatible with Atom 1.0. Such feeds SHOULD be considered invalid Atom 1.0. ]]] cheers Bill
Re: Old application/atom+xml issues
Robert Sayre wrote: I worry that any statement like Bill's suggested text will confer legitimacy on Atom 0.3 as long as the RFC is available. *Every* current implementor is aware of the issue, so the short term benefit of such text is pretty much nil. Long term, the text will actually be harmful. +1 to this sentiment - I take it this means we're saying no to the interop text in the spec?
Re: Dealing with namespace prefixes when syndicating signed entries
Antone Roundy wrote: [...] Perhaps a reasonable way to deal with the namespace prefix conflict would be for the signature to be applied after a transform that yielded this (putting full namespace names in where the prefixes were): [...] ex-c14n is where to deal with this - it's a necessary preprocessing step to dsigging XML and walks the line between the Infoset and bytewise needs. IIRC it can result in moving the namespace declarations around. cheers Bill
Re: Microsoft, RSS Atom
James M Snell wrote: Regarding the list extensions themselves, technically they're actually rather boring ;-) Having lists that can live outside the server or application they were created for is a big deal. If we were talking about the next step in bringing the web to its full potential, then machine readable lists are that step. There's oceans and oceans of data in list form. cheers Bill
Re: Microsoft, RSS Atom
James M Snell wrote: No doubt. I didn't say the applications that could be built with the extensions are boring... I said the extensions themselves were boring. In other words, while I (and quite a few others it would appear) would have done it differently, they're so minimal and simple that there's really not a lot to debate about 'em. I bet someone said that about line feeds once, now look where we are :) cheers Bill
Re: Polling Sucks! (was RE: Atom feed synchronization)
Bob Wyman wrote: Joe Gregorio wrote: The one thing missing from the analysis is the overhead, and practicality, of switching protocols (HTTP to XMPP). I'm not aware of anything that might be called overhead. What our clients do is, upon startup, connect to XMPP and request the list of Atom files that they are monitoring. They then immediately fetch those files to establish their start-of-session state. From that point on, they only listen to XMPP since anything that would be written to the Atom files is also written to XMPP. HTTP is only used on start-up. It's a pretty clean process. I'm guessing Joe is talking about network administration. There's no shortage of places that won't even let you use SSH or POP, never mind on XMPP. It's port 80 via the proxy or nothing. This is an observation of the current state of affairs, please don't confuse it with an advocacy of it. cheers Bill
Re: Polling Sucks! (was RE: Atom feed synchronization)
Eric Scheid wrote: how does Atom over XMPP help in this scenario: 1) wake up 2) scratch myself, stagger around in morning fog 3) turn on computer, launch feed reader 4) wonder what changes happened during the night This is not the thread you're looking for - go back to bed! cheers Bill
Re: first request for an atom extension: Re: Polling Sucks! (was RE: Atom feed synchronization)
Henry Story wrote: [...] Something like: link rel=http://.../next; href=http://bblfish.net/blog/archive/ 2005-05-10.atom would be really useful. Henry, Mark Nottingham did something on this a while back; try digging through the archives. cheers Bill
Re: Atom feed synchronization
James M Snell wrote: Ok, question for the group. Scenario: A content source is updated 100 times per hour. The Atom feed currently only displays the 20 most recent entries. Users who are not checking the feed every 10 minutes or so are missing entries. How do we address this? Solution: Rather than using a feed with a fixed number of entries, provide a mechanism that allows users to specify the last time they retrieved the feed and have the feed return all entries added since that time. Question: What is the best way to provide that mechanism: querystring parameter or HTTP header or some other way I'm not thinking of http://...?last-retrieved=12345 OR GET ... HTTP/1.1 Host: ... Last-Retrieved: 12345 We found shared time imprecise enough, and other workarounds over HTTP complex enough, that to solve this problem (must get all entires) we pushed the feed out using XMPP. All the technical problems I saw then came down to inconsistent rates of change. The simplest answer was to get rid of HTTP and use XMPP. cheers Bill
Re: Atom feed synchronization
Antone Roundy wrote: On Thursday, June 16, 2005, at 04:37 PM, James M Snell wrote: Scenario: A content source is updated 100 times per hour. The Atom feed currently only displays the 20 most recent entries. Users who are not checking the feed every 10 minutes or so are missing entries. How do we address this? 1) Tell users to poll more frequently--if they don't, that's their problem Doesn't solve the problem, probably makes things worse. 2) Make the feed longer than 20 entries Same as 1) 2a) If the feed is SOMETIMES updated 100 times per hour, but sometimes only twice per hour, dynamically set the feed length--when regenerating the feed, include all entries updated in the last hour or so, down to some minimum number Same as 2) 3) Push instead of pull This works. 4) Create a new link @rel to point to the next X entries and keep a series of static documents containing the older entries Might work, but requires at least as much extra mechanism as a query param. cheers Bill
Re: More on Atom XML signatures and encryption
James M Snell wrote: Thoughts? The mot straightforward way (imo) to deal with encoded fragments is to use two attributes, ie @type and @enc. So defining a new extension attribute would work for me. I'm not sure you need to deal with signalling the type of a fully encrypted document in your case 5; if it's not possible to signal the type via xmlenc I'd claim it's a spec bug there, not here. cheers Bill
Re: OpenSearch RSS
Thomas Broyer wrote: Tim Bray wrote: Check out A9's OpenSearch at http://opensearch.a9.com/ - I'm starting to hear substantial buzz around this thing. I wonder, is embedding the OpenSearch RSS stuff in Atom going to cause any heartburn? I'm inclined to think not, but would appreciate others having a look. I get the feeling that OpenSearch + Atom could be real useful. -Tim * I set type=text/html on the feed's alternate link, because the OpenSearch RSS 1.0 Specification [1] says the RSS link is a URL that can recreate the search in HTML format, @type is not used in entries as it might not be text/html * I changed the escaped-HTML amp;copy; to #169;, it saves us an internal DTD subset while allowing us to use type=text * Atom mandates an atom:author, I added a dummy one * Atom mandates an atom:updated in the feed, I added a dummy one; it should be set to the latest atom:updated date found in the feed's entries, or at least to the date the request was made. * Atom mandates an atom:updated in each entry, I added a dummy one; it should be set to the last access of the search engine to the result document, or eventually the date the request was made. For example, Google is able to give you this date if it has cached the document (when you look at a cached page, Google puts a this is Google's cache of URI as retrieved on DATE on top of the page. * I used the address of the result document (permalink?) as the atom:id of each entry, because this is the easiest way to do it... I did the same experiment; bottom line Amazon will need to add -atom:updated -atom:id -atom:modified -a few attributes to use Atom. They also need to fix their example*, it's invalid XML (copy; in the last entry). By the looks of things, with the feed level extensions, they're going the route Nature have taken with RSS1.0. cheers Bill * http://opensearch.a9.com/spec/opensearchrss/1.0/
Re: OpenSearch RSS
Bill de hÓra wrote: I did the same experiment; bottom line Amazon will need to add [...] Oops, please ignore: -atom:modified [My eyes! The specifications! They do nothing!] cheers Bill
Re: atom:type, xsl:output
James Cerra wrote: So do I. That's why the spec should state that any XML fragments embedded into atom:content as an XML tree become part of that tree. So PIs become associated with the Atom document rather than the content, for example. If the entry MUST be preserved unmodified (Author's intention), the spec should either specify that it must be associated externally via @src or encoded via entities or base64 like any other non-xml-compatible formats in the current draft. This is why MIME is still a good idea. cheers Bill
Re: PaceAtomIdDos posted (was Re: Consensus snapshot, 2005/05/25)
James M Snell wrote: Ignoring the overhead that it adds for now, isn't this the kind of situation digital signatures are designed to handle? Yes. Norm and I have mentioned this as well. I do not think we can solve this problem by patching the Atom level, ensuring that the Atom level can be ex-canonicalised and signed is sufficient. If I put out an entry with a given ID and digitally sign it, and someone comes along and attempts to publish an entry with a duplicate ID and updated timestamp and it is NOT signed with the same key my original was signed with, then hey, Houston we've got a problem. Without any kind of cryptographic guarantee of this sort, the best you could do is make an educated guess. Would it make sense to include some language along these lines? Belongs in the security sections. I would trust the editors to add the text if they were willing. cheers Bill
Re: some small comments on 08
Thomas Broyer wrote: Bill de hÓra wrote: Thomas Broyer wrote: * it is not less reliably implementable than the current draft's mandatory div element; if we go for a SHOULD or MAY on discarding the div elements, it is even *more* reliably implementable. We had a discussion about optional div not so long ago, and I came away unconvinced then. Can you present some arguments to back those opinions up? As you're quoting the reliable implementation sentence, let's start with some code and pseudo code to demonstrate PaceOptionalXhtmlDiv is reliably implementable: With a pull parser (.NET XmlReader, or DOM), using recursivity: function getContent(nodelist) returns nodelist if nodelist.length = 1 then # a single element var element = nodelist[0] if element is xhtml:div and not(element has attributes) then # the single element is a discardable xhtml:div # apply the same function on its children (recursivity) return getContent(element.children) else return nodelist end if else return nodelist end if end function ... The above function would be called like this: if element is atom:content and [EMAIL PROTECTED]xhtml then content = getContent(element.children) end if if xhtmlTypeContent(element ,'atom:content'): return stripContentFromDiv(element.child[0]) ie, when the @type=xhtml, pull back all the children underneath the xhtml:div child. Done. With less options come less conditionals. What's broken if broken is clearly determinable. There's no need to check for a discardable divs when the first child under content is assured to be. Btw, from what I found in the archives for the last two months (approximately), it seems that what bothers you is less the optional div than linking Atom to XHTML or even more generally use XML in XML. What bothers me is inconsistent document production. Optionality of this feature invites that, ie making it optional defeats its purpose. There's no apparent benefit. I'm open to discussion if you have a problem with something particular in my proposal, but actually, without some hint, it'd be hard for me to find other arguments. I don't buy the rationale for xhtml:div optionality and I've refuted it already. I'll sum up: You said- I just want the XHTML div to be optional for people that don't need it but still meeting other people's needs of a dummy container to carry their XHTML namespace declarations I said- If you can't trust people not to need the div, then you can't make it optional. I unfortunately have a good amount of experience dealing with this kind of thing outside Atompub. The simplest answer is to stop the 'envelope' from using a default namespace (don't bother to debate this with me, it's not an imo). We're not doing that with Atom. Failing that, the next thing consideration is to add/enforce a protective scoping barrier between the envelope and the content. We are doing that with Atom. You need to convince me why making this thing optional is beneficial. Thats not happening, what's happening is that you're telling me optionality, if we allow it, can be worked around, as long as everyone works around it the same way. One problem here is that you're assuming that the people who don't need this and the people who do this need won't cross each others paths. They will. If that is not a problem, then we can remove the construct altogether. I explained in [1] that a div (without attribute and without sibling) has no meaning and is never necessary. That's refutable - xhtml:div is a lexical scoping mechanism, it doesn't require meaning to be useful, and such a mechanism is clearly neccessary (according to the WG) in the presence of Atom created with default namespaces. What being proposed is not ime a robust solution and I would much rather we take our chances without such a mechanism that make it optional. Unless there are new arguments regarding the benefit of optionality, this is just restating positions and we remain deadlocked. If it is necessary in the application processing the Atom document, it's the responsibility of that application to add it. If it is necessary in the application producing the Atom document and this one has no mean to strip it, the Pace allows this application to put that div in the Text Construct or atom:content, it just says that such a div has no more meaning than the Atom element containing it (that is, grouping its content altogether) and thus will be discarded by the Atom Processor at the other end of the chain. Note that I'm open to change the MUST discard into a SHOULD, as there is no real need for this discarding. Don't do that. It's enlarging the state space; more conditionals to think about. Actually, that Pace wouldn't have been necessary if people wanting to produce prefix-free feeds weren't bothered adding a dummy div to achieve their taste and having it become part
Re: Consensus snapshot, 2005/05/25
Tim Bray wrote: Have I missed any? Yes, there has been high-volume debate on several other issues; but have there been any other outcomes where we can reasonably claim consensus exists? -Tim Good summary, thank you. cheers Bill
Re: some small comments on 08
Thomas Broyer wrote: * it is not less reliably implementable than the current draft's mandatory div element; if we go for a SHOULD or MAY on discarding the div elements, it is even *more* reliably implementable. We had a discussion about optional div not so long ago, and I came away unconvinced then. Can you present some arguments to back those opinions up? cheers Bill
Re: spec text regarding feed/entry inheritance
Dan Brickley wrote: Is anybody working on a set of AtomPub test cases? Not quite; I'm working up some sample documents around authoring in particular to see if the WG could agree on the author/contributors for particular entries. I'm waiting until the next draft ships before raising that here. In Atom, re inheritance, it'd be great just having a collection of pairs of Atom docs, and a flag to say whether the first can be considered implied (eg. by inheritance rules) from the second. That's a good approach. ps. is it only built-in properties from the Atom ns that can be inherited? Or extensions too? Again, this will reviewed when the next draft comes around. cheers Bill
Re: inheritance issues
Eric Scheid wrote: oh darn. This damn inheritance stuff is nasty. Inheritance suggests a programming model to allow the evaluator to be coded for it. It's rarely as simple as it looks to define a decent model that does what people think it does at first glance. As things stand, it will be an immense coincidence if we do not end up dishing out nasty surprises for users. Atom's just not a very good programming language ;) cheers Bill
Re: A different question about atom:author and inheritance
Tim Bray wrote: Anybody think this is anything more than an editorial change? -Tim Not me (you'd have to tell me that inheritance applies at all, not the other way around). But the rules must be consistent for the elements that appear at both levels. cheers Bill
Re: A different question about atom:author and inheritance
Bill de hÓra wrote: Tim Bray wrote: Anybody think this is anything more than an editorial change? -Tim Not me (you'd have to tell me that inheritance applies at all, not the other way around). But the rules must be consistent for the elements that appear at both levels. Quick followup: I'll take an action to review the upcoming format draft to see if we need to apply any such wording to feed level extensions. cheers Bill
Re: Fetch me an author. Now, fetch me another author.
Tim Bray wrote: A scan of the archives reveals no discussion; i.e. this rule is something that predates the move to the IETF. I believe that (with a bit of offline help) I can explain the reasoning though. We were trying to borrow the Dublin Core semantics, wherein there is the notion of an Entity Primarily Responsible, dc:creator. So, Atom gives you that with atom:author and the notion of a contributor in atom:contributor. I also scanned the archives and found no consensus. Let me speak as a victim of a few years in the publishing-software trenches: The semantics of author and contributor are a tangled mess, a real swamp, and I don't think that Atom is going to do a very good job of solving them. In particular, I don't think we're going to a better job than Dublin Core. That is to say, if we were to do as some suggest (nuke atom:contributor and make atom:author repeatable) I'm quite certain that we could come up with all sorts of corner cases and problems, probably about as many as with the current setup. I observe this is one of the problems with borrowing semantics without attribution and without consultation. You might be quite certain, but the fact is we don't know. So, bearing that in mind, and also bearing in mind Paul's recent essay on process, I'm strongly -1 on any change whatsoever to the current definition of author and contributor. -Tim As co-chair, please instruct the editors to add spec text mentioning this rationale, it is hardly satisfactory to have that constraint in there as it stands. It's tempting now to perform due diligence, and go through every constraint in the spec and cross-reference consensus. cheers Bill
Re: Fetch me an author. Now, fetch me another author.
Robert Sayre wrote: On 5/21/05, Bill de hÓra [EMAIL PROTECTED] wrote: I also scanned the archives and found no consensus. I can point you to many discussions surrounding atom:author. Thanks for the offer, but I've already done that for myself. I don't much care for the number of discussions, I care about this specification and whether it has consensus. Can you find one discussion that addresses cardinality? Most of the ones I saw when I grepped through the archives seemed to focus on feed/entry inheritance. Here's one: http://www.imc.org/atom-syntax/mail-archive/msg13793.html The requirement made it through nine drafts, much discussion, and two last calls. I don't think you have a consensus argument. If you don't think I have a consensus argument, you should be able to demonstrate that by pointing me at consensus. Look. I understand the process more or less says we're done, I read Paul's mail, and as the editor I do appreciate your sentiments and opinion on this. If there is consensus and I missed it, I'll withdraw and apologise for distracting the WG. If an IETF process wizard says it's too late now, technically or in the spirit of things, I'll withdraw. If the WG makes it known that at this point in the process, I have to like them apples, we're shipping, I'll withdraw. Otherwise as a WG member I'm of the opinion that letting a specification get through that has no consensus, and that we know has no consensus, is irresponsible. cheers Bill
Re: multiple atom:author elements?
Eric Scheid wrote: Science Journals are just one example of feeds which require being able to specify multiple authors per entry. I have Library clients who want to make their indexing efforts available in XML form - currently I can recommend RSS 1.0, but I would like to be able to recommend Atom 1.0 when it becomes available. With a one-author-per-article restriction this would be impossible. Shall I write a Pace? Legal documents and legislation are others. Good catch Eric. I'll support this. cheers Bill
Re: multiple atom:author elements?
Robert Sayre wrote: On 5/20/05, Bill de hÓra [EMAIL PROTECTED] wrote: Legal documents and legislation are others. Good catch Eric. I'll support this. Those are three terrible use cases. Let's suppose there's general agreement here with that opinion. The things to ask here nonetheless are a) whether drilling multiple author names through a name element indicates a design flaw in Atom (overconstraint). b) whether multiple authoring is an edge-case; it could well be. I'm open to persuasion on b); it's not my intent to force this anyone's throat. But a) does bother me. Shall we go through every element in the format and evaluate their fitness for scientific journals, legal documents, and legislation? Unfair :\ Not the least because you're assuming that hasn't been done. cheers Bill
Re: Consensus call on last raft of issues
Tim Bray wrote: Conclusion: This Pace is rejected. However, the editors are directed to include the following text in 4.2.13: Experience teaches that feeds which contain textual content are in general more useful than those which do not. There are certain classes of application, for example full-text indexers, which will be unable to make effective use of entries which do not contain text in either atom:summary or atom:content. Feed producers should be aware of these issues and are encouraged to include a meaningful atom:summary in entries lacking atom:content wherever possible. However, the absence of atom:summary is not an error and software MUST NOT fail to function correctly as a consequence of such an absence. +1 cheers Bill
Re: Accidental and intentional atom:id collisions (was Re: Consensus call on last raft of issues)
Antone Roundy wrote: This is already bad enough. Now how about if the phishing feed claims that it's atom:id is http://a.com/feeda. Worse still. With the current spec text, an Atom consumer that does a little extra work, somehow figures out that the phishing version of the entry is not the same as the legitimate version, and tells the user that would be violating the spec. I don't think this (spam, phishing) is solvable without widespread adoption of dsig/pki technology. More snarkily, all the people who complain about these things ought to consider using appropriate technology. We do need to make sure that Atom entries are easily signed tho'. cheers Bill
Re: extensions -- Atom NS and unprefixed attributes
Robert Sayre wrote: On 5/16/05, Bill de hÓra [EMAIL PROTECTED] wrote: Too terse - I don't understand why you're asking this. But if you really think that we allow everything we don't ban, we should say that somewhere in the spec. hmm. I could write that Pace if you want, but maybe it would be more productive to explain why you find my interpretation psychotic. Because it's an interpretation that cares not for others. I could ask if you could maybe explain why that was more a productive direction, but isn't this getting silly now? Maybe you could point to some spec text to back up your opinion. Postel's law. MarkN seems to think its only this or other IETF working groups that can extend the Atom namespace. I don't see anything in the spec about that. Let's agree I made an error of judgement in my characterisation and call your interpretation something neutral instead - interpretation-x. As I've withdrawn 'psychotic' I think it's reasonable to say we can stop quibbling and move on. The point remains - if you think interpretation-x is valid way of systematically evaluating the spec, then there is room to discuss whether we should make mention of it. Will you address now whether we should mention or approve that interpretation in the spec? cheers Bill
Re: extensions -- Atom NS and unprefixed attributes
Robert Sayre wrote: On 5/16/05, Tim Bray [EMAIL PROTECTED] wrote: My problem is that putting text in the format spec saying Nobody but the IETF can extend the namespace feels empty and useless, are we going to send Marshall Rose over to beat up anyone who tries? It will happen and we won't be able to stop it. I have a question - what's the problem? cheers Bill
Re: extensions -- Atom NS and unprefixed attributes
Robert Sayre wrote: On 5/16/05, Bill de hÓra [EMAIL PROTECTED] wrote: Robert Sayre wrote: On 5/16/05, Tim Bray [EMAIL PROTECTED] wrote: My problem is that putting text in the format spec saying Nobody but the IETF can extend the namespace feels empty and useless, are we going to send Marshall Rose over to beat up anyone who tries? It will happen and we won't be able to stop it. I have a question - what's the problem? I can think of a couple things. One would be collisions (which Sam mentioned). I don't understand- maybe I'm looking at the wrong post? http://www.imc.org/atom-syntax/mail-archive/msg15236.html Another would be that validators couldn't catch typos. Validators won't be able to catch typos for optional markup. cheers Bill
Re: extensions -- Atom NS and unprefixed attributes
Robert Sayre wrote: On 5/16/05, Bill de hÓra [EMAIL PROTECTED] wrote: I can think of a couple things. One would be collisions (which Sam mentioned). I don't understand- maybe I'm looking at the wrong post? http://www.imc.org/atom-syntax/mail-archive/msg15236.html Sam is saying that the IETF can't add a new element to the Atom namespace and be sure there would be no collision. I still don't understand. Can't the IETF read their own specs? Another would be that validators couldn't catch typos. Validators won't be able to catch typos for optional markup. If there is a non-optional piece of markup expected, and you enter a typo instead of it, it won't be in the markup, then a validator won't find it, hence the validator will flag that something is missing. What do you mean? The extended example in the spec has a generator element. The RNC has caught me adding an attribute called 'url'. Can validators catch typos or not? You seem to be saying they can't, but they did catch you adding an attribute called url. I'm honestly not getting the gist of this issue, sorry. cheers Bill
Re: extensions -- Atom NS and unprefixed attributes
Robert Sayre wrote: On 5/16/05, Bill de hÓra [EMAIL PROTECTED] wrote: Robert Sayre wrote: On 5/16/05, Bill de hÓra [EMAIL PROTECTED] wrote: I can think of a couple things. One would be collisions (which Sam mentioned). I don't understand- maybe I'm looking at the wrong post? http://www.imc.org/atom-syntax/mail-archive/msg15236.html Sam is saying that the IETF can't add a new element to the Atom namespace and be sure there would be no collision. I still don't understand. Can't the IETF read their own specs? The spec allows anyone to add stuff to the Atom namespace, so the IETF will have to read everyone's documents before they add something to the Atom namespace. The spec does no such thing; that's a psychotic interpretation at best. If people are going to add stuff to the Atom namespace, then they're going to add stuff to the Atom namespace, irrespective of what the spec says. Your options are to live with that or enforce the building of machinery that will reject the markup of people who do it. To build that machinery you'll have to have an ability to proof-check the markup. To proof-check the markup you have to have to ensure its legal names and their combinations can be enumerated at design time - at a minimum. Maybe you folks are implying that collisions just aren't a problem. If they are a problem, then they're universal to XML+namespaces. I'll argue we're not hear to solve that (possible) problem, even if we are responsible for choosing that technology to begin with. One approach for minimising honest-john name collisions for attributes is to state that further added attributes be namespace qualified. If we are still worried about unprefixed attributes, we can either ban them all except for the ones we have designed, or ban them all and place the ones we have inside the atom namespace. Either way, no further unprefixed attributes will be accepted by validators than the ones we mandate now. I suppose if we're going to worry about this stuff, let's worry about these too: - will it be hard for people to use atom attributes outside atom? - will adding new attributes result in spec combination breakage a la the recent situations with new xml:* attributes? [But personally speaking, I find this debate unimportant compared to consequences of say default namespaces and the introduction of xhtml:div] Can validators catch typos or not? You seem to be saying they can't, but they did catch you adding an attribute called url. I'm honestly not getting the gist of this issue, sorry. If anyone can add unqualified attributes, how can the validator distinguish between a typo and an extension? For non-optional attributes, a validator will pick up on a typo to non-optional attribute by way of the non-optional attribute not being there. * Optional attributes can't easily be distinguished because you can't enumerate all of them in advance - formally, that would be a non-existence of bugs class problem. But as they're optional, it's not a disaster. If it is a disaster, we have a design problem first and foremost, not a validation problem. cheers Bill * barring statistically unfortunate events like a typing an attribute in once mistakenly and then typing it in correctly.
Re: extensions -- Atom NS and unprefixed attributes
Robert Sayre wrote: On 5/16/05, Bill de hÓra [EMAIL PROTECTED] wrote: Only, and this is not a joke, if you agree to add the text What this specification doesn't ban, it allows. Let's leave no room for doubt as to the spirit of interpretation. Future versions of this specification could add new elements and attributes to the Atom markup vocabulary. Software written to conform to this version of the specification will not be able to process such markup correctly and, in fact, will not be able to distinguish it from markup error. What error would that be? Too terse - I don't understand why you're asking this. But if you really think that we allow everything we don't ban, we should say that somewhere in the spec. cheers Bill
Re: PaceOptionalXhtmlDiv
Thomas Broyer wrote: I might have not be enough explicit in what I'm suggesting with this Pace: I just want the XHTML div to be optional for people that don't need it but still meeting other people's needs of a dummy container to carry their XHTML namespace declarations. That way, those two summaries would be equivalent: atom:summary type=xhtml xmlns:atom=...Atom NS... xmlns=...XHTML NS... This is a emsample/em summary. /atom:summary summary type=xhtml xmlns=...Atom NS... div xmlns=... XHTML NS... This is a emsample/em summary. /div /summary -1 to PaceOptionalXhtmlDiv. If we are dealing with systems where a div wrapper is deemed neccessary, then you want to take steps to miminise people's options. For example, PaceOptionalXhtmlDiv will help this to occur: summary type=xhtml xmlns:atom=...Atom NS... xmlns=...XHTML NS... This is one busted-ass document - emyow!/em. /summary If you can't trust people not to need the div, then you can't make it optional. I unfortunately have a good amount of experience dealing with this kind of thing outside Atompub. The simplest answer is to stop the 'envelope' from using a default namespace (don't bother to debate this with me, it's not an imo). We're not doing that with Atom. Failing that, the next thing consideration is to add/enforce a protective scoping barrier between the envelope and the content. We are doing that with Atom. [I disagree with Graham btw, and would say xhtml:div is actually fighting kluges with kluges, but it works more or less as specified.] cheers Bill
Re: atom:updated vs entry inheritance?
Eric Scheid wrote: I agree. You can see how easy it would be to not do that though. It could also be argued that the publisher has signalled the significance by updating /feed/updated, and thus effectively /feed/entry/. The ambiguity bothers me. thus effectively, does not follow. That's not warranted unless we say it is. There's no ambiguity, at best there's an optical illusion provided by looking at an XML structure with programming language scope rules in mind. If you're still concerned people are going to get the wrong impression, I'd probably support spec text making such scoping matters explicit - I imagine this would result in a subsection since dates are not the only issue I think. cheers Bill
Re: Atom 1.0?
Henri Sivonen wrote: Marketing: Atom I'm looking forward to an article by Mark Pilgrim about the incompatible versions of Atom deceitfully marketed as one thing. :-) (Which is why I said +1 to Atom 1.0.) ARSS, short for Atom RSS. The marketing possibilities are endless. cheers Bill
Re: PaceOptionalSummary
Tim Bray wrote: On May 10, 2005, at 4:37 AM, Graham wrote: Let's forget about Paces for a minute. Does anyone disagree with the principal of recommending publishers include summaries if they have them available, and aren't supplying atom:content? Yes, but I'd go further; I'd like to encourage, in general, producers to put more than less stuff in feeds, and provide a summary whenever they possibly can. My only angst at this moment is whether the canonical SHOULD is the right tool to do that. -Tim MAY is the requirement level I would choose for something like a summary, which isn't a control code or interoperability hotspot. My sense of things, based on the paces and discussion I've seen, is that MAY won't accord sufficient moral obligation to gain consensus here. Perhaps that can be offset by producing text that urges the publisher to consider emitting summaries. cheers Bill
Re: PaceOptionalSummary
A. Pagaltzis wrote: * Bill de hra [EMAIL PROTECTED] [2005-05-10 17:00]: Perhaps that can be offset by producing text that urges the publisher to consider emitting summaries. Maybe its something for the implemetors guide as opposed to the spec, then? I raised that question already: http://www.mail-archive.com/atom-syntax@mail.imc.org/msg02809.html the WG didn't discuss it in follow-up (I think). cheers Bill
PaceNoAlternateForFeed
http://www.intertwingly.net/wiki/pie/PaceNoAlternateForFeed
== Abstract ==
Allow publishers to indicate when they have no alternate link for a feed.
Author: BillDehora
== Status ==
Open
Incept: 2005-05-09
Written against:
http://www.ietf.org/internet-drafts/draft-ietf-atompub-format-08.txt
== Rationale ==
Not all publishers have a suitable alternate link for a feed. Example
cases include subversion repositories [1], and mail archives [2].
== Proposal ==
In section 4.1.1 change the tenth bullet point
{{{
o atom:feed elements MUST contain at least one atom:link element
with a relation of alternate.
}}}
to
{{{
o atom:feed elements MUST contain either and cannot contain both
- one or more atom:link elements with a relation of alternate.
- one and only one atom:link element with a relation of
no-alternate.
}}}
== Impacts ==
* PaceFeedIdOrAlternate: none, that pace is withdrawn.
* PaceFeedIdOrSelf: that pace suggests pointing to self in the absence
of an atom:[EMAIL PROTECTED]'alternate'] or an atom:id. This pace suggests
allowing the publisher to state there is no alternate.
== Notes ==
Fragment example derived from 1.1 example 2 in draft-08
{{{
feed xmlns=http://purl.org/atom/ns#draft-ietf-atompub-format-08;
title type=textdive into mark/title
subtitle type=html
A lt;emgt;lotlt;/emgt; of effort
went into making this effortless
/subtitle
updated2005-04-02T12:29:29Z/updated
idtag:example.org,2003:3/id
link rel=no-alternate /
copyrightCopyright (c) 2003, Mark Pilgrim/copyright
}}}
* The author is not attached to the token 'no-alternate'. Any other
token is fine once we agree that it states the publisher is saying there
is no alternate link for this feed.
* The author is fine with a SHOULD provide rather than MUST provide.
* Whether atom:feed/atom:id MUST be present in the absence of an
alternate be present can be argued about separately from whether there
is no alternate. see PaceFeedIdOrSelf.
cheers
Bill
[1] http://www.imc.org/atom-syntax/mail-archive/msg13995.html
[2] http://www.imc.org/atom-syntax/mail-archive/msg13978.html
Re: PaceNoAlternateForFeed
Tim Bray wrote: On May 9, 2005, at 8:13 AM, Bill de hÓra wrote: Why can't ve just leave a protocol element out if we don't have information for it??? Because it allows someone to assert there is no alternate link for their feed. That's different from leaving an alternate link out. What observable difference in the behavior of software would be affected by this difference? It's not obvious to me that there's a meaningful difference. -Tim The difference is in what can be concluded from the data, ie it's a 3-valued logic problem. Does the absence mean there's no alternate? Does it mean don't unknown? Do we need to care? I think this exercise is *critical* for any piece of markup that is going to move from mandatory to optional. Either way, we should pin down spec language around the optionality of alternate feed links, or consciously decide we're not going to pin it down. cheers Bill
Re: PaceNoAlternateForFeed
Graham wrote: On 9 May 2005, at 6:48 pm, Bill de hÓra wrote: I think this exercise is *critical* for any piece of markup that is going to move from mandatory to optional. Either way, we should pin down spec language around the optionality of alternate feed links, or consciously decide we're not going to pin it down. So you wouldn't support a proposal that removed a required element without explaining what it's absence meant (eg PaceAtomSummary), because you'd prefer one that leaves it much less ambiguous (eg PaceTextShouldBeProvided, which strongly encourages publishers to only omit atom:summary when none exists)? I'm not surprised at this line of thought since there is also another dicussion going on around optional summaries. You're jumping the gun though and/or possibly trying to pin me into some kind of non-existent corner - fair enough. What I would like is that we at least discuss the consequences of making non-optional things optional on the data beynd some people can't supply meaningful alternates - I happen to be one of those people btw, if I haven't said it already. And some consistency of debate around loosening constraints is good I think. Finally, there is an important distinction between the two cases (optional alternates and optional summaries). The difference is in what can be concluded from the data, ie it's a 3-valued logic problem. Does the absence mean there's no alternate? Does it mean don't unknown? Do we need to care? Answer Tim's question: What observable difference in the behavior of software would be affected by this difference? I can have nullable columns in my database depending on what we decide to do here. That affects the behaviour of my SQL queries and depending. I can can constrain the search for alternates in a nypertext graph if I know the author is saying there is no alternate. That affects (massively in some cases) the behaviour of an RDF query backend among other things. similar arguments can be made for search systems that are working off raw indexes. I can send the message there is no alternate for this feed or no alternate was provided for this feed or no alternate was found for this feed depending on what we decide to do here. Is that enough? Do you see that the point of this pace is to shine some light on what we're doing here? Btw, I'm 0 on PaceNoAlternateForFeed - like I said, I have feeds that have no real alternates. cheers Bill
Re: PaceAllowDuplicateIDs
Robert Sayre wrote: I'm much more sympathetic to the aggregate feed problem of multiple IDs. People advocating this type of thing seem to think the default action should be grouping, so they want to use the same ID. I think that's a bad idea, and there are plenty of other ways to indicate the fundamental sameness of entries. For example, NewsML URNs have a NewsItemID and a RevisionID, which would allow smart aggregators to group the entries without violating Atom's constraint. Then you have two ways of indicating fundamental sameness of entries, one for when the same entry appears multiple times in a feed, and one for everything else. Back to basics then. Does anyone remember why having the same id in a feed is a bad idea? cheers Bill
