Re: PaceOptionalFeedLink
At 11:50 05/05/06, Sam Ruby wrote: Tim Bray wrote: +1 There are people who want to publish feeds without rel=alternate links. I'm against telling people they can't do something they want to do without strong reasons, as in loss of interoperability. I don't see the reasons here as strong enough. -Tim +1 here, too, since long ago. FYI: we have an instance proof of this requiring an existing tool to do additional work: http://www.imc.org/atom-syntax/mail-archive/msg13983.html Well, yes, but how much work can that possibly be? Regards,Martin.
Re: Last Call: 'The Atom Syndication Format' to Proposed Standard
At 02:27 05/05/04, Thomas Broyer wrote: Martin Duerst wrote: At 03:33 05/04/29, Alexey Melnikov wrote: If the value is text, the content of the Text construct MUST NOT contain child elements. Such text is intended to be presented to humans in a readable fashion. Thus, Atom Processors MAY collapse white-space (including line-breaks), Ok, maybe it is just me, but what does it mean to collapse white-space? Does this mean to replace FWS (in RFC 2822 sense) with a single space? Making this more precise is definitely desirable. But there is also an i18n issue: This works fine for languages that use spaces between words. It doesn't work for languages that don't have spaces between words (Chinese, Japanese, Thai,...). If Text elements are only used for short things such as names or titles, that's not a big issue, the text in question can just be put on a single line. However, when the texts in question are long, it's a serious issue, and should be fixed. My understanding of type=text is that this is just text without any formatting. That's my understanding, too. Hence, it is not meant to be preformatted text such as text/plain or inside an (X)HTML pre. Yes. But that's exactly where the spacing problems with Chinese/Japanese/Thai are. There are no such problems for preformatted text, because the line breaking in the source (as sent) is the same as the line breaking when displayed. For free-flowing text, however, the line breaks in the source and those in the display are not (necessarily) the same, and so linebreaks have to be changed to spaces for Western languages, but to nothing for Chinese/Japanese (and most possibly to a zero-width non-breaking space for Thai), and the spec has to say something about this. Regards,Martin. This means type=text content is a single paragraph of text. If you need paragraphs, lists or any other structural formatting, you have to use type=html or type=xhtml with the appropriate content. I was about to writing a Pace about white-space handling in type=text (either using xml:space or an attribute that would have mimic'd the white-space CSS property) when I understood/recalled that Text Constructs have accessibility in mind (hence their limitation to textual contents) and preformatted text is not accessible enough. -- Thomas Broyer
Re: PaceAllowDuplicateIDs
I have no good answer to that until I know what what an id stands for. The answer an entry isn't sufficient. Bill: Semi-random thoughts... * An atom:id is a globally unique name for a specific database query. * There is no stream of instances over time. There's just old data that's out of sync with that query. * If duplicate ids are allowed, the world won't come to an end. I'm almost sure. I think. -- Roger Benningfield
Re: PaceTextShouldBeProvided vs PaceOptionalSummary
Yes. If that SHOULD goes through, it becomes OK to write an Atom Processor that catches fire when summary and content are both absent. Robert: Nothing about either pace will make it not OK to drop content- and summary-free entries on the floor, or come to a full stop when they're encountered. Such feeds would be completely useless in some apps, and therefore deserve to be tossed. PaceOptionalSummary simply enables an infinite loop of talk to the other guy about that responses to user questions, while PaceTextShouldBeProvided says that the tie goes to the aggregator. Kinda funny when you look at it that way, given the heated discussion on the subject. They could both be rolled into a single PaceWhoYouGonnaBlame and save everyone unnecessary reading. -- Roger Benningfield
Re: PaceAllowDuplicateIDs alteration
On 7/5/05 3:53 AM, Tim Bray [EMAIL PROTECTED] wrote: On May 6, 2005, at 8:49 AM, Eric Scheid wrote: Are they still the same entry if they have different source elements that identify their source as being different feeds? I don't see why. I subscribe to a Local News feed, a National News feed, and a Science News feed. All from the same publisher. The same story may appear in one, two, or three of those feeds. I don't believe each of those feeds would have the same feed/source values. Right but the story's atom:entry would have the same atom:id in each of those feeds, right? So they are the same entry, right? -Tim typo: I don't see why not. d'oh! (Tim: yes) e.
the atom:copyright element
The publication of a new Implementation Guideline by the Open Archives Initiative (OAI) compels me to suggest once again [1], as Norm Walsh [2], Bob Wyman [3], and others have done before, that the name 'atom:rights' would be better than the (current) element name 'atom:copyright'. Since this element name change is not likely to have any secondary ramifications that would affect other areas of the format design, it should be harmless. Using the element name 'atom:rights', as argued below, could enhance interoperability and avoid some unforeseen and unintended legal implications that may emerge from use of the term (copyright). The term copyright has an established legal meaning -- or rather, set of established legal meanings, in various languages and jurisdictions, whereas rights is capable of a generic meaning that extends to the rights of readers (consumers) as well as to the rights of authors (creators). Why should the Atom spec support the latter and not the former? I agree with 99% of earlier list postings [0] to the effect that: DRM is a snakepit; we don't want to come anywhere near it; DRM patent terrorism is a scourge; rights management constructs per se DO NOT belong in the Atom design, etc. So, I do not advocate 'atom:rights' over 'atom:copyright' because I want Atom to support rights management (enforcement), but because I think using 'atom:copyright' gives privilege to the wrong set of stakeholders, and potentially leads to a legal mess. The label rights has no clear association with intellectual property law(s); by its genericity, it would allow for and support the (established) concept of IP rights claim + prohibition against copy/reuse/CreateDerivativeWork, which roughly == copyright, while allowing other concepts like you're free to use this, please include some kind of attribution for the source, thanks! Stated otherwise, a declaration like (version -08 example) copyrightCopyright (c) 2003, Mark Pilgrim/copyright serves the need of an author to assert IP ownership and to (possibly) discourage certain -- but unclear -- uses of the embedding Atom entry/feed. A declaration copyright... /copyright does nothing to encourage syndication, or to clearly communicate that the content of an Atom feed/entry may be re-used freely, by permission. Two other major initiatives have recognized that rights properly belong to users/readers as well as to authors, and have registered this opinion in the technical design of XML markup vocabularies: the Open Archives Initiative (OAI) [4] and Dublin Core Metadata Initiative (DCMI) [5]. OAI supports a model for federated databases and unified search engines that access archives at hundreds of digital libraries and archive centers; DCMI's Dublin Core metadata model has been adopted for use in many HTML, XHTML, and XML markup applications. Formal specifications from both organizations allow generic rights markup elements that contain free-form text as well as by-reference (URI) pointers to resources that document the relevant rights -- which users are free to consult or ignore. I believe the Atom spec can do this similarly (and minimally) with an 'atom:rights' element in place of 'atom:copyright'. It can do so optimally by allowing one (optional) generic URI reference to a resource that documents the rights statement(s) from the creator of an Atom feed/entry. Something non-legal, like 'rightsDescription=URI'. I predict that if the Atom spec does not make this kind of accommodation to support this widely attested requirement, multiple (incompatible) ad hoc solutions will be invented, alongside widespread abuse of the 'atom:copyright' element. Surely, multiple (incompatible) ad hoc solutions will be invented ANYWAY, but providing the basic markup construct in the Atom syntax spec would point users in the right direction, rather than leaving them directionless. In making this request for WG reconsideration of the appropriateness of the element name 'atom:copyright', I respect the fact that the The Atom Syndication Format specification is in last call [6], near that finish line and onto the last lap [7]. Thanks, Robin Cover OASIS XML Cover Pages http://xml.coverpages.org/ PS [Bob Wyman,] Note that I have not referenced the Creative Commons or (machine-readable) licenses at all in the above. While I approve of both, I think any such use should be a decision left to an Atom author -- and I do not think it should be the role of the Atom spec designers to positively *prevent* an Atom author from referencing a machine-readable license in an unambiguous manner if s/he wishes to do so. Surely, enabling an Atom author to clearly declare her/his intent is preferable to enforcing intentional prose ambiguity through spec constraints. == Excursus on OAI and DCMI models for rights == I would *NOT* recommend modeling any Atom design after the OAI and DCMI designs, specifically, and I would *NOT* suggest that Atom recommend any behavior with respect to
Re: the atom:copyright element
At 6:29 PM -0400 5/7/05, Robin Cover wrote: The publication of a new Implementation Guideline by the Open Archives Initiative (OAI) compels me to suggest once again [1], as Norm Walsh [2], Bob Wyman [3], and others have done before, that the name 'atom:rights' would be better than the (current) element name 'atom:copyright'. As before, -1. In fact, I would prefer to remove atom:copyright from the core before we make a post-last-call move to substitute a less-defined element such as atom:rights. Since this element name change is not likely to have any secondary ramifications that would affect other areas of the format design, it should be harmless. Fully disagree. Later, you suggested that the renamed element would have a URI that pointed to the rights asserted by the author. That has a *lot* of effects, including the need for someone to resolve that URI before republishing the content in another feed, and storing the resolution of that URI with a copy of the contents (so that that author can't change the contents and then come after you). That is far from harmless. Using the element name 'atom:rights', as argued below, could enhance interoperability Sorry, I didn't see anything in the rest of the post that showed how this could increase interop. Please be specific here. To me, you can't get much more interoperable than an unstructured, human-readable, free-text blob such as atom:copyright. and avoid some unforeseen and unintended legal implications that may emerge from use of the term (copyright). Legal FUD doesn't help here. The current atom:copyright entry has no properties different than allowing someone to type in whatever human-readable copyright notice they want in an HTML document. If someone is comfortable with asserting a copyright, they can; if they're not, they don't have to. Something non-legal, like 'rightsDescription=URI'. Please explain how rightsDescription is non-legal while copyright is legal. Seriously, I don't see how they can be differentiated. If you claim particular rights, that's a legal assertion of the same strength as claiming a copyright. I predict that if the Atom spec does not make this kind of accommodation to support this widely attested requirement, multiple (incompatible) ad hoc solutions will be invented, alongside widespread abuse of the 'atom:copyright' element. Surely, multiple (incompatible) ad hoc solutions will be invented ANYWAY, but providing the basic markup construct in the Atom syntax spec would point users in the right direction, rather than leaving them directionless. This goes back to the question of what goes into the core and what is done as an extension. I would strongly support the latter because, as you posit, people will disagree on how they should be able to assert rights. Coming up with a single extension structure that will keep everyone happy will take a lot of wrangling, but the effort would probably be worth it. --Paul Hoffman, Director --Internet Mail Consortium
Re: PaceCaching
--On May 6, 2005 4:28:44 PM -0700 Paul Hoffman [EMAIL PROTECTED] wrote: -1. Having two mechanisms in two different layers is a recipe for disaster. If HTTP headers are good enough for everything else on the web, they're good enough for Atom. That would be a problem. But this is one mechanism with two ways to specify it. One is out-of-band in a server-specific way, the other is in the document in a standard way. Either way, it is HTTP rules for caching at all intermediate caches and at the client. Architecturally, this is exactly the same as HTTP-EQUIV meta tags for HTTP headers, and very similar to the ROBOTS meta tag for /robots.txt. In both cases, they provide a way for the document author to specify something without having permissions on the server software config. Further, these should be implemented exactly like HTTP-EQUIV, where the server software reads them and sets the header. The HTTP-EQUIV meta tag is proof put it in the header is not good enough for everything else. If that wasn't needed, it would be deprecated by now. There is a problem here, though. We need to specify the priority of the in-document specs vs. the HTTP header specs. I propose following the HTTP standard, in saying that the HTTP headers trump anything in the body. I'll even assume that following the HTTP spec is non-controversial, and go update the PACE. wunder -- Walter Underwood Principal Architect, Verity
Re: Last Call: 'The Atom Syndication Format' to Proposed Standard
--On May 7, 2005 11:29:07 AM +0300 Henri Sivonen [EMAIL PROTECTED] wrote: Why would you put line breaks in the CJK source, then? Isn't the problem solved with the least heuristics by the producer not putting breaks there? It would be even better if they would just speak English. :-) White space is not particularly meaningful in some of these languages, so we cannot expect them to suddenly pay attention to that just so they can use Atom. There will be plenty of content from other formats with this linguistically meaningless white space. If we get this wrong, Atom-delivered content will look broken in some languages, and a bunch of extra-spec practice will build up about how to fix it. Much better to get it right in 1.0. wunder -- Walter Underwood Principal Architect, Verity
