Re: I-D ACTION:draft-ietf-atompub-typeparam-00.txt
On Thu, 11 Jan 2007 11:41:36 +0100, Andreas Sewe [EMAIL PROTECTED] wrote: The OP has a (different) point, though: Recommending distinct file extensions for application/atom+xml; type=entry and application/atom+xml; type=feed is worthwhile. If, e.g., the mime.types shipped with Apache already contains appropriate entries, this would aid the fast adoption of the new, parameterized application/atom+xml. Hence it would be worthwhile to include file extension recommendations in the I-D. Indeed. +1. -- Asbjørn Ulsberg -=|=-http://virtuelvis.com/quark/ «He's a loathsome offensive brute, yet I can't look away»
Re: Additional 'namespace' attribute on content element?
On Fri, 05 Jan 2007 13:26:46 +0100, Henri Sivonen [EMAIL PROTECTED] wrote: Atom is quite reasonable here. An XML vocabulary that doesn't have a MIME type that follows the convention *and* doesn't have a namespace is itself a badly-behaved XML vocabulary. My point exactly. -- Asbjørn Ulsberg -=|=-http://virtuelvis.com/quark/ «He's a loathsome offensive brute, yet I can't look away»
Re: I-D ACTION:draft-ietf-atompub-typeparam-00.txt
On Thu, 04 Jan 2007 23:12:15 +0100, James M Snell [EMAIL PROTECTED] wrote: Bob Wyman wrote: It is strongly recommended that Atom processors that do recognize the parameter detect and report I have no problem with the rewording. Just waiting to see what others may have to say about it. I also like Bob's wording better. -- Asbjørn Ulsberg -=|=-http://virtuelvis.com/quark/ «He's a loathsome offensive brute, yet I can't look away»
Re: Fwd: Atom format interpretation question
On Fri, 05 Jan 2007 05:22:30 +0100, Tim Bray [EMAIL PROTECTED] wrote: John Cowan wrote: Am I right in thinking that content which is in fact in XML but is labeled with a media type that is neither generic XML nor ends in +xml cannot be included inline in an Atom entry? The NewsML community (which uses the registered media-type text/vnd.IPTC.NewsML) is concerned about this. We've already discussed this in another thread, but since the question is asked in a different way here, I'd like to answer it again. John is partly right, but only because NewsML neither has a namespace nor an XML MIME type. If it had either, embedding it as XML in Atom would be no problem at all. Thus, my conclusion is that this is a problem with NewsML and not with Atom. -- Asbjørn Ulsberg -=|=-http://virtuelvis.com/quark/ «He's a loathsome offensive brute, yet I can't look away»
Re: Fwd: Atom format interpretation question
On Fri, 05 Jan 2007 05:56:29 +0100, James M Snell [EMAIL PROTECTED] wrote: If the NewsML folks want to be able to use a proper media type to identify their stuff AND treat it as XML, they should come up with an appropriate media type registration (e.g. application/newsml+xml, etc). - Or come up with an appropriate namespace URI. Both solutions work just as well imo, but I'd prefer both together over just one or the other, though. That is, both a new MIME type (that ends with '+xml') and a namespace URI. -- Asbjørn Ulsberg -=|=-http://virtuelvis.com/quark/ «He's a loathsome offensive brute, yet I can't look away»
Re: Additional 'namespace' attribute on content element?
On Thu, 04 Jan 2007 17:00:29 +0100, Jan Algermissen [EMAIL PROTECTED] wrote: on the NewsML list, an issue came up that due to they lack of a MIME type for NewsML using NewsML as Atom content is somewhat problematic[1]; I think this is the case with most of the more interesting XML applications out there. The more interesting XML applications out there should get a proper MIME type, that's all. Nothing wrong with Atom in this case, imo. -- Asbjørn Ulsberg -=|=-http://virtuelvis.com/quark/ «He's a loathsome offensive brute, yet I can't look away»
Re: base within HTML content
On Fri, 22 Dec 2006 18:38:33 +0100, Geoffrey Sneddon [EMAIL PROTECTED] wrote: If we come across something like: description type=html![CDATA [base url=http://example.com/;a href=test.htmlTest Link/a]] /description, Yikes! I assume the link should point to http://example.com/test.html, due to the base element? I assume, likewise, that base would take precedence over xml:base, as it is directly within the content. Like James Holderness wrote, the base element has no place in an HTML fragment, so its meaning is (although most browsers wrongfully supports its presence anywhere in an HTML document) unspecified. The correct base URI to use here is the closest xml:base in the ancestor vector or the document's base URI. What's the use case for not using xml:base here? -- Asbjørn Ulsberg -=|=-http://virtuelvis.com/quark/ «He's a loathsome offensive brute, yet I can't look away»
Re: Atom Entry docs
On Tue, 19 Dec 2006 21:27:07 +0100, James M Snell [EMAIL PROTECTED] wrote: Ok, so we've had more than just a few people put up their hands and say what Bob said. This week I'll go ahead write up an initial draft of this using the type param option while we wait for the co-chairs to do their hasty consensus grab :-) «What James said.» ;) -- Asbjørn Ulsberg -=|=-http://virtuelvis.com/quark/ «He's a loathsome offensive brute, yet I can't look away»
Re: Atom Entry docs
On Sat, 16 Dec 2006 01:31:29 +0100, John Panzer [EMAIL PROTECTED] wrote: Or both. Millions of blog entry pages have both an entry and a set of comments on that entry. Yes, it's stretching the concept of 'alternate' a long, long way. Yes, it's a long stretch. RFC 4685 specifies how to build that relationship; rel=alternate is not the appropriate solution. In any case, the relation type 'feed' would be better suited for the feed reference and 'alternate' would suit the Entry reference if the Entry indeed was an alternate representation of the HTML document. Agreed, in an ideal world. Considering that the 'feed' relationship is being baked in WHATWG, I don't think that ideal world is such a utopia. -- Asbjørn Ulsberg -=|=-http://virtuelvis.com/quark/ «He's a loathsome offensive brute, yet I can't look away»
Re: Atom Entry docs
On Fri, 15 Dec 2006 13:47:05 +0100, David Powell [EMAIL PROTECTED] wrote: An example would be an HTML page with rel=alternative links pointing to a feed and an Atom Entry document. My thought on this is that that's actually broken. If not according to RFC 4287 or anything else, it's most likely wrong semantics involved. Ether the current HTML document is an alternate representation of the Atom Entry, or it is an alternate representation of the Feed. In any case, the relation type 'feed' would be better suited for the feed reference and 'alternate' would suit the Entry reference if the Entry indeed was an alternate representation of the HTML document. Alternate representation of web site front pages are typically Feeds, alternate representations of article pages are typically Entries. There's very few cases where a Feed and an Entry can be alternate representations of the same resource. -- Asbjørn Ulsberg -=|=-http://virtuelvis.com/quark/ «He's a loathsome offensive brute, yet I can't look away»
Re: Atom Entry Documents
On Tue, 12 Dec 2006 23:25:44 +0100, Tim Bray [EMAIL PROTECTED] wrote: [...] So I see no downside in James doing an I-D. But is a separate I-D really necessary? If, like Kyle Marvin suggests, the new MIME type for Atom Entries actually becomes a type parameter of the existing Atom MIME type, can't the language that specifies this be included in the APP specification? By that, APP will only extend RFC 4287 and not deprecate anything. It might include wording like SHOULD use the type parameter, but that still makes the old and bare MIME type valid. Thus, implementing RFC 4287 will not require you to use a type parameter, but implementing the APP specification will strongly encourage you to do so. Won't that solve it all? -- Asbjørn Ulsberg -=|=-http://virtuelvis.com/quark/ «He's a loathsome offensive brute, yet I can't look away»
Re: Atom Entry Documents
On Tue, 12 Dec 2006 08:39:25 +0100, James M Snell [EMAIL PROTECTED] wrote: Ideally, I would much rather this be a WG draft. I pinged Tim about it the other day and he suggested that I go ahead with a I-D for now and that we can explore whether or not to move forward with it as a WG draft later. Can't just the APP specification include language that specifies a new MIME type for Atom Entries, since it's mostly APP implementations that have a use for it? Or would that be totally out of place? -- Asbjørn Ulsberg -=|=-http://virtuelvis.com/quark/ «He's a loathsome offensive brute, yet I can't look away»
Re: Atom Entry docs
On Thu, 14 Dec 2006 18:00:17 +0100, Tim Bray [EMAIL PROTECTED] wrote: Bob Wyman wrote: There is, I think, a compromise position here which will avoid breaking those existing implementations which follow the existing RFC's. co-chair-modeIn case you haven't noticed, the WG is hopelessly split between the new-media-type option and the media-type-parameter option. If a few people were to put up their hands and say yeah what Bob said your co-chairs would probably do a hasty consensus grab./co-chair-mode *Hands up* «What Bob said» -- Asbjørn Ulsberg -=|=-http://virtuelvis.com/quark/ «He's a loathsome offensive brute, yet I can't look away»
Re: Atom Entry Documents
On Fri, 15 Dec 2006 01:40:01 +0100, James M Snell [EMAIL PROTECTED] wrote: Quite a few folks seemed to have a preference to a separate doc. What does quite a few folks mean wrt consensus? What reasons are there not to include this in the APP specification? -- Asbjørn Ulsberg -=|=-http://virtuelvis.com/quark/ «He's a loathsome offensive brute, yet I can't look away»
Re: Atom Entry Documents
On Sun, 10 Dec 2006 20:19:53 +0100, James M Snell [EMAIL PROTECTED] wrote: Option A) Optional Type Param application/atom+xml; type=entry application/atom+xml; type=feed +1. I believe that a type parameter allows more smoothly for new types to be introduced in the future, plus it more clearly states that it is an Atom resource than a completely new MIME type. All in my humble opinion of course. This is just a matter of taste, afaict. -- Asbjørn Ulsberg -=|=-http://virtuelvis.com/quark/ «He's a loathsome offensive brute, yet I can't look away»
Re: PaceEntryMediatype
On Wed, 06 Dec 2006 20:42:40 +0100, Jan Algermissen [EMAIL PROTECTED] wrote: But that is an issue of linking semantics, not link target media types. Wrong. The link relation 'alternate' is perfectly valid for both Entry and Feed documents, depending on what type of resource they are linked from. An index page of a website can have an 'alternate' relation to an Atom Feed, while an individual article page (or entry page) can have an 'alternate' relation to an Atom Entry. Both link relations are identical, but the client has absolutely no clue before it GETs the URI whether what sits on the other end is an Atom Feed or an Atom Entry. Let's take Firefox as an example of a feed reader. When you browse to a page saying it has 'alternate' resources, you get a nice little orange subscribe button in the address field. Pushing it makes you a subscriber of that alternate resource. On an index page, that's fine, because the alternate resource is an Atom Feed. However, on an individual article page, Firefox will still display the subscribe button although it doesn't support subscribtion to the resource and subscribing to it in the first place doesn't make much sense. Wouldn't it be a better experience to not get the subscribe button on the article page at all? Or do you prefer that it's there and that you need to press it and get an error message (that you most probably won't understand if you're not a technical user like you and me) to know that you can't subscribe to this alternate resource after all? What do you think? I'd expect the user agent to look for links with 'here is a feed' semantics instead of looking for (arbitrary) links to certain media types. The 'alternate' relation is fine for both uses. However, the WHATWG propsed 'feed' relation is a bit more explicit on the subscribe to me part. Still, an Atom Feed can be 'alternate' of an index page just as an Atom Entry can be 'alternate' of an article page. People shouldn't be forced to use the 'feed' relation, and I highly doubt that the widely deployed 'alternate' relation can be replaced that easilly. -- Asbjørn Ulsberg -=|=-http://virtuelvis.com/quark/ «He's a loathsome offensive brute, yet I can't look away»
Re: Fwd: PaceEntryMediatype
On Fri, 08 Dec 2006 18:52:05 +0100, James M Snell [EMAIL PROTECTED] wrote: I'm fine with the type parameter approach so long as it is effective. By effective I mean: Will existing implementations actually take the time to update their behavior to properly handle the optional type parameter. Seeing how eager most applications have been to implement Atom support, I believe the answer to this question is yes. I'm optimistic at least. -- Asbjørn Ulsberg -=|=-http://virtuelvis.com/quark/ «He's a loathsome offensive brute, yet I can't look away»
Re: PaceEntryMediatype
On Thu, 07 Dec 2006 13:58:55 +0100, Jan Algermissen [EMAIL PROTECTED] wrote: Ok, that is IMO heading in the right direction. This example makes sense because it strongly emphasizes a difference between feeds and entries, saying feeds are for viewing collections and entries are more or less for editing web resources (if we include the media resource case). Yay, the discussion is progressing! :) If the Atom specs never considered feed readers to be dealing with individual entries anyhow (at least that is the impression I get by now) then having a new media type does indeed make sense. Yes indeed. Question to Atom editors and others involved with the specs: What was the intention behind having entry documents in Atom in the first place? I don't remember all about the original discussion, but here's three of my entries from back in the days: http://www.imc.org/atom-syntax/mail-archive/msg04647.html http://www.imc.org/atom-syntax/mail-archive/msg04386.html http://www.imc.org/atom-syntax/mail-archive/msg08599.html Although the topics in which the messages appear are unrelated, they all talk about the same thing, namely having Atom Entries as first-class web citizens. Back then, reaching this goal was enough of a struggle; defining Atom Entries' own MIME type was unthinkable. -- Asbjørn Ulsberg -=|=-http://virtuelvis.com/quark/ «He's a loathsome offensive brute, yet I can't look away»
Re: PaceEntryMediatype
On Wed, 06 Dec 2006 05:22:24 +0100, Mark Baker [EMAIL PROTECTED] wrote: It wasn't the most illustrative choice of words, but what I'm looking for is evidence that an entry is interpreted differently if it's found in an entry document, than if it were found in a feed document. If we turn up multiple interoperable examples of that, then a new media type is warranted because it's really two formats masquerading as one. To turn it a bit around: Would you ever want to subscribe to a single Atom Entry? If not, wouldn't it be good to know that it was an Atom Entry and not an Atom Feed before you started subscribing to it? -- Asbjørn Ulsberg -=|=-http://virtuelvis.com/quark/ «He's a loathsome offensive brute, yet I can't look away»
Re: PaceEntryMediatype
On Wed, 06 Dec 2006 19:14:04 +0100, Jan Algermissen [EMAIL PROTECTED] wrote: This is misleading wording (and maybe part of the overall problem)! Perhaps, but it describes one of the most important use-cases with feeds -- which won't be the one with entries. Following a link is not the same thing as subscribing to something. Of course not. The act of subscribing is a local activity performed by the user agent. What you do when you follow the link to a feed is a GET. Yep. But why would you do the GET in the first place? In what use case scenario would you put GET-ing an URI that returns an Atom Entry compared to one that returns an Atom Feed? Your agent then decides if subscribing to that resource is a good idea. How does it decide? By parsing the whole document first, e.g. content sniffing? To make that decision, the agent has to look at the representation and the it is insignificant overhead to see if the thing returnes feed or entry. Not if the resource needn't be GET in the first place. If the whole operation can be decided upon the Content-Type returned in a HEAD request, or even better; by the value in the @type attribute of whatever element referring to this resource, the client won't have to do a GET at all on resources it doesn't know how to handle properly. Most feed readers knows how to handle feeds, but have no idea how to handle entries. When pointed at a URI they can say Hey, I can't subscribe to this! if the Content-Type is 'text/html', 'application/octet-stream' or whatever, but if the Content-Type is 'application/atom+xml', they think Hey, this is a feed I can subscribe to! and will in most cases fail because what they're trying to subscribe to isn't an Atom Feed but an Atom Entry. Knowing before the GET whether the resource can be subscribed to (or whatever you may want to do with either entries or feeds separately) or not is useful information. And please note that subscribe is used here as a single use-case for the endless amounts of use-cases that will differ for Atom Feeds and Atom Entries. Anyhow, why not monitor a single entry? That's of course possible, but you will be monitoring indirectly if you're subscribing to a feed that has that entry and changes to that entry gets re-published to the same feed. However, that's not the issue at hand here. I think this is far more a user agent configuration issue than it is a problem of the media type being returned. I disagree. FWIW, I think the question of media type (or the feed-ness of some resource) and the issue of whether to subscribe or not are completely orthogonal. They are and they aren't. -- Asbjørn Ulsberg -=|=-http://virtuelvis.com/quark/ «He's a loathsome offensive brute, yet I can't look away»
Re: PaceEntryMediatype
On Wed, 29 Nov 2006 20:03:22 +0100, Thomas Broyer [EMAIL PROTECTED] wrote: I'd largely prefer augmenting the existing media type with a 'type' parameter: - application/atom+xml = either feed or entry (as defined in RFC4287) - application/atom+xml;type=feed = feed - application/atom+xml;type=entry = entry +1. How about defining a tree similar to the */vnd.* one? - application/atom+xml = feed or entry document - application/atom.categories+xml = category document - application/atom.service+xml = service document ...and of course, if this proposal is finally accepted: - application/atom.entry+xml = entry document I think 'type=*' is a cleaner solution, but both serves the same purpose so I'm not religious about which solution we choose. But I agree that distinguishing between entries, feeds and every other atom resource is indeed useful. +1. As for Tim's concerns, I'd also prefer having it done outside the APP. Yep. Also, the APP draft would need to be updated to remove the entry special value for app:accept, as it would be equivalent to the new or revised media type (app:accept=application/atom+xml;type=entry or app:accept=applicationAtom.entry+xml) Of course. -- Asbjørn Ulsberg -=|=-http://virtuelvis.com/quark/ «He's a loathsome offensive brute, yet I can't look away»
Re: PaceEntryMediatype
On Fri, 01 Dec 2006 19:42:20 +0100, Kyle Marvin [EMAIL PROTECTED] wrote: This points out that the above rel+type don't carry sufficient semantic meaning to help a UA decide what to do with them. I don't think anyone on this thread is disagreeing with that. This discussion (as I understand it) is about what to do given that ambiguity. You can either get more specific with the rel value, with the content-type, or with both. The problem with baking the necessary information for this particular use case inside the 'rel' value is that we possibly need a million different 'rel' values for a million diffierent use cases, or what we'll see is semantic overloading where 'rel' values are abused to mean different things in different use cases and that again will hurt interoperability. Instead, we can let consumers define their own use cases upon the given content type and not push our pre-defined use cases (in the form of 'rel' values) down their throat because we're too reluctant to expand the MIME type of atom with a 'type' attribute (or something similar). Are we confident enough about Atom's entire spectre of use cases to say that different 'rel' values are sufficient? I think not. Give consumers the correct content type of the resource instead, and they can themselves decide what to do with it, on the base of a more general 'rel' value that don't dictate what they can and can't do with it. 'rel' values are not sufficient to solve this issue imo. We need something less fine-grained and more generic. We need to define this at the HTTP level. -- Asbjørn Ulsberg -=|=-http://virtuelvis.com/quark/ «He's a loathsome offensive brute, yet I can't look away»
Re: Author element best practice
On Mon, 27 Nov 2006 08:39:41 +0100, Sylvain Hellegouarch [EMAIL PROTECTED] wrote: Mind you considering that RFC 4287 is very clear on what makes an Atom entry a valid one I imagine APP servers which don't have the necessary context will decide to reject the request altogether. Am I the only one pondering and worrying about what the different server implementations will respond to invalid client requests (as, for example, an invalid Atom document)? How can the client implementors be interoperable and compatible with each other and every server implementation if the specification says absolutely nothing about what to expect when something goes wrong? HTTP covers some of the possible errors one might encounter, but I believe there are several cases in APP where errors might occur that HTTP does not cover and that server implementors will treat very differently. In most server application frameworks, unhandled exceptions give the response 500 Server Error. Is that the appropriate response to give on most errors? Which errors should yield which 4xx response? Is this not an issue? How can a client tell the user how to correct something if the client have no idea what response to expect from the server? -- Asbjørn Ulsberg -=|=-http://virtuelvis.com/quark/ «He's a loathsome offensive brute, yet I can't look away»
Re: Author element best practice
On Wed, 22 Nov 2006 23:50:14 +0100, Sylvain Hellegouarch [EMAIL PROTECTED] wrote: [...] how would people feel about stating in the draft that the server MAY (SHOULD?) reject an Atom entry which would be invalid as per RFC 4287 ? +1 to MAY, -1 to SHOULD. I think at least a MAY would give some weigh to implementors who wish to be really strict regarding the input the allow. The be lenient in what you accept rule should not apply for APP, imo. If APP implementations get too lenient, the output we get in the other end will be even more lenient. Crap in, crap out, basically. So +1. -- Asbjørn Ulsberg -=|=-http://virtuelvis.com/quark/ «He's a loathsome offensive brute, yet I can't look away»
Re: [atom-syntax] [RFC 4685] uri in xml namespace
On Fri, 10 Nov 2006 08:01:07 +0100, Martin Duerst [EMAIL PROTECTED] wrote: A good example is the XHTML namespace URI: http://www.w3.org/1999/xhtml Yes, this is a good example in general, but misses one important point. It should say explicitly that the namespace URI is http://www.w3.org/1999/xhtml. I agree. Let's hope James takes this into consideration when he creates the HTML document for the Atom namespace URI. -- Asbjørn Ulsberg -=|=-http://virtuelvis.com/quark/ «He's a loathsome offensive brute, yet I can't look away»
Re: [atom-syntax] [RFC 4685] uri in xml namespace
On Sun, 05 Nov 2006 06:47:23 +0100, Judy Piper [EMAIL PROTECTED] wrote: I was expecting a Namespace document that explains the namespace URI itself and the relationship between the spec and the URI. Am I wrong to expect this behavior? What is to be expected when resolving a namespace URI is undefined, but a common solution is to have a document explaining what the URI means and how the vocabulary residing in that namespace can be used. In other words; just as you say. Redirecting directly to the specification works, but an informative and perhaps more human friendly document inbetween would indeed be nice. A good example is the XHTML namespace URI: http://www.w3.org/1999/xhtml -- Asbjørn Ulsberg -=|=-http://virtuelvis.com/quark/ «He's a loathsome offensive brute, yet I can't look away»
Re: Can/Does/Should the FeedValidator catch improperly escaped XHTML?
On Fri, 01 Sep 2006 01:19:35 +0200, James Holderness [EMAIL PROTECTED] wrote: Just because a feed appears to contain well-formed xhtml content today, that doesn't mean it's going to be well-formed tomorrow. Encouraging people to use xhtml when they don't know enough to have made that decision themselves is just asking for trouble. Sooner or later they're going to end up with broken xml which will be completely unreadable in many aggregators. Well, that completely depends on how we present this information to the user. I was not thinking of a simple message saying This is valid XHTML, change @type to 'xhtml' ASAP, you newb!, but more along the lines of informing the user that the content looks like wellformed XHTML, that he can read more about it here and there, why he should try to keep it wellformed and why he should not change it if he's not sure of its welformedness. Something like that. Also, escaped html tends to be better supported by aggregators anyway. That's today. I would hope and assume that this changes in the future. -- Asbjørn Ulsberg -=|=-http://virtuelvis.com/quark/ «He's a loathsome offensive brute, yet I can't look away»
Re: Can/Does/Should the FeedValidator catch improperly escaped XHTML?
On Thu, 31 Aug 2006 13:50:56 +0200, Sam Ruby [EMAIL PROTECTED] wrote: Also, there are a number of tools that attempt to produce well-formed XHTML, but don't do so consistently enough to drop the content into an Atom feed in such a manner. But is it possible to check the wellformedness of the markup inside atom:content and suggest that the authors use 'type=xhtml' instead of 'type=html' if it is indeed wellformed X(HT)ML? It's a real stretch in terms of how far the validator should go, but I can definately see its usefulness. -- Asbjørn Ulsberg -=|=-http://virtuelvis.com/quark/ «He's a loathsome offensive brute, yet I can't look away»
Re: More on atom:id handling
On Wed, 01 Feb 2006 17:01:38 +0100, David Powell [EMAIL PROTECTED] wrote: On the contrary, I have a problem with preventing multiple revisions from having the same atom:updated value. It subverts the intent of atom:updated being a subjective element, and it puts the feed compiler in an impossible situation. Nothing prohibits the entry author from producing two different instances with the same atom:updated value, but given this valid situation, the feed compiler is forced to silently lose data. This goes way back to the days we discussed this, and different ways of signaling change to the user. I was always for the more automatic, strict and professional publishing-centric way of doing it, with atom:modified which got changed with every revision of the entry, no matter how significant. This didn't fit the blogging community too well, though, so the conclusion came to something less strict and thus we have atom:updated. I don't think there's anything constructive to get out from surfacing that discussion again, but I might of course be wrong. -- Asbjørn Ulsberg -=|=-http://virtuelvis.com/quark/ «He's a loathsome offensive brute, yet I can't look away»
Re: The Atomic age
On Fri, 15 Jul 2005 10:32:29 +0200, Anne van Kesteren [EMAIL PROTECTED] wrote: Yay! I second this yay. Yay! (Except for the namespace that is. Ouch!) Yea, that was a bit awkward. The format has a couple of other minor flaws as well, but nothing worth fighting for and nothing serious at all. This is a good specification, all in all. -- Asbjørn Ulsberg «He's a loathsome offensive brute, yet I can't look away»
Re: The atom:uri element
On Tue, 28 Jun 2005 03:21:19 +0200, James Cerra [EMAIL PROTECTED] wrote: I knew that, but I was unaware of how un-updatable a step that was. I apologize for my ignorance. The same goes for me. No. I thought that there was room for updates to the draft during IESG consideration. That stemmed from unwarranted assumptions on my part, though. Same here. On the other hand, if the spec is sent back by the IESG for other reasons then I suggest revisiting this issue. That sounds like a good idea. -- Asbjørn Ulsberg -=|=-http://virtuelvis.com/quark/ «He's a loathsome offensive brute, yet I can't look away»
Re: The atom:uri element
On Thu, 26 May 2005 17:13:22 +0200, Eric Scheid [EMAIL PROTECTED] wrote: See http://www.imc.org/atom-syntax/mail-archive/msg13864.html There are two arguments in parallel here: (1) which is the proper term for a url/uri/iri ? (2) is naming an element after the data type sensible ? I say the first argument is a red herring, a bike shed, and entirely redundant as we've already extensively used IRI in the spec. Consider also: http://www.imc.org/atom-syntax/mail-archive/msg13860.html We have /author/name and not /author/string for a reason. Why then do we have /author/uri? I guess we won't be nuking the atom:uri element before Atom goes gold? I've created a Pace just to have a final stab at it, if it's possible to do anything about it: http://intertwingly.net/wiki/pie/PaceRenameUriElement == Abstract == The atom:uri element should be renamed or changed. == Author == AsbjornUlsberg == Status == Open. == Rationale == The atom:uri element says nothing about its semantics or meaning, just about the datatype of its content. As [http://www.imc.org/atom-syntax/mail-archive/msg13860.html Danny Ayers writes]: Using atom:uri/atom:iri is only marginally better than saying atom:string - it describes how the identifier is put together, it tells you nothing about what's being identified.. It is also in conflict with the term IRI which is the one used in the rest of the specification. == Proposal == Rename the atom:uri element or change its type to a Link Construct. == Impacts == Atom parsers which expects atom:uri in the documents, although they are based on a non-standard nor final version of the Atom document format. == Notes == As this change is mostly editorial and not technical, I think the authors are free to find the best suited name for the element. -- Asbjørn Ulsberg -=|=-http://virtuelvis.com/quark/ «He's a loathsome offensive brute, yet I can't look away»
Re: The atom:uri element
On Mon, 27 Jun 2005 14:22:34 +0200, Dave Pawson [EMAIL PROTECTED] wrote: I support the rationale for changing. I'd appreciate even more some semantics for the element? I agree and have added text to the pace that describes this. I will try to add wording for the specification when I find time for it. Not describing what we mean with this element might hurt interop and that should be avioded. -- Asbjørn Ulsberg -=|=-http://virtuelvis.com/quark/ «He's a loathsome offensive brute, yet I can't look away»
Re: The atom:uri element
On Wed, 25 May 2005 06:45:29 +0200, Eric Scheid [EMAIL PROTECTED] wrote: In this instance, I think atom:name, atom:resource, or atom:link works better. +1 atom:link I think atom:[EMAIL PROTECTED] works even better. Thinking of what information is stored in atom:uri and how it is used, why isn't it just an attribute? It's a single value intended for computers, not humans, to parse. The atom:uri element does not have a 'title' attribute or anything else that makes it necessary to keep it as an element, the actual name of the element is awkward in this context and it is not consistent with the rest of the specification to have URI's as text nodes of elements but rather as attribute values (of @src and @href attributes respectively). Consistency makes the format easier to understand and learn. Isn't that something worth stribing (and thus changing) for? -- Asbjørn Ulsberg -=|=-http://virtuelvis.com/quark/ «He's a loathsome offensive brute, yet I can't look away»
Re: The atom:uri element
On Wed, 25 May 2005 14:53:05 +0200, Graham [EMAIL PROTECTED] wrote: -1 to atom:link unless they are proper link elements. What about atom:[EMAIL PROTECTED], then? I'm fairly happy with the current situation. Okay, but do you agree that the atom:uri element is a bit inconsistent with the rest of the format specification? -- Asbjørn Ulsberg -=|=-http://virtuelvis.com/quark/ «He's a loathsome offensive brute, yet I can't look away»
Re: Fetch me an author. Now, fetch me another author.
On Sat, 21 May 2005 17:16:25 +0200, Eric Scheid [EMAIL PROTECTED] wrote: what if author in that example was renamed to byline (and specced to be something other than a Person Construct), and some mechanism introduced to indicate the nature of the contribution by each of the contributors? +1. This makes very much sense to me from a publishing company point of view. -- Asbjørn Ulsberg -=|=-http://virtuelvis.com/quark/ «He's a loathsome offensive brute, yet I can't look away»
The atom:uri element
I've mentioned this several times before and haven't had time to follow the evolvement of the draft up until now, but as far as I can tell, atom:uri is still in place in the specification... Do we really need a pace to have that element renamed before the spec goes final? Or is it so that the atom:uri element have many proponents on the list so it can't be renamed or changed to atom:link, atom:email or something making more sense? Even atom:iri is better at this point, imho. -- Asbjørn Ulsberg -=|=-http://virtuelvis.com/quark/ «He's a loathsome offensive brute, yet I can't look away»
Re: some small comments on 08
On Mon, 23 May 2005 08:54:32 +0200, Anne van Kesteren [EMAIL PROTECTED] wrote: * 4.2.2 The atom:category Element Why is significant information hidden in attributes? That is bad for i18n and prevents people from defining the expansion of an abbreviation, for example. Minor flaw. It happens. I think you are rushing things too fast. It would be much better if we fixed this. I agree. Can't we name them consistently? I'd suggest 'href' or 'url'. Nope. Too late. And this. +2. -- Asbjørn Ulsberg -=|=-http://virtuelvis.com/quark/ «He's a loathsome offensive brute, yet I can't look away»
Re: The atom:uri element
On Tue, 24 May 2005 14:40:41 +0200, Asbjørn Ulsberg [EMAIL PROTECTED] wrote: Or is it so that the atom:uri element have many proponents on the list so it can't be renamed or changed to atom:link, atom:email or something [...] ^^ Just so the replies to this e-mail (if any) doesn't get concentrated around my little mishap with the elements here: I didn't mean writing 'atom:email' there since we already have that element. The point I'm trying to make is not the name of the element, but rather its type. I'd like it to be constructed somewhat similar to atom:link, e.g. be an Atom Link Construct. -- Asbjørn Ulsberg -=|=-http://virtuelvis.com/quark/ «He's a loathsome offensive brute, yet I can't look away»
Re: Author and contributor
On Mon, 23 May 2005 07:22:49 +0200, A. Pagaltzis [EMAIL PROTECTED] wrote: make atom:author plural keep atom:contributor punt bylines to an extension It's the best suggestion made so far that has any potential of getting into the spec until christmas, so I'm +1 on this. :-) -- Asbjrn Ulsberg -=|=-http://virtuelvis.com/quark/ He's a loathsome offensive brute, yet I can't look away
Re: hreflang attribute should be allowed to be empty as well
On Tue, 03 May 2005 13:11:51 +0200, Anne van Kesteren [EMAIL PROTECTED] wrote: I think that the HREFLANG attribute[1] should be allowed to be empty as well, just like xml:lang is allowed to be empty. I'm +1 to this. It makes sense. -- Asbjørn Ulsberg -=|=-http://virtuelvis.com/quark/ «He's a loathsome offensive brute, yet I can't look away»
Re: Getting atom:source right
On Mon, 02 May 2005 23:13:06 +0200, Antone Roundy [EMAIL PROTECTED] wrote: Should we add something like this? If an atom:entry element already containing an atom:source element is copied to another feed, the contents of the atom:source element MUST NOT be replaced with metadata from the containing atom:feed. I think I understand what you want, but I'm having difficulties reading the paragraph. If I misunderstand (or don't undersand it at all ;-) it, perhaps readers and implementors of the Atom spec. will as well? That's implied by if it is not already present in the entry, but it may be best to be more explicit. I agree. But I'm not sure the intended message is communicated clearly enough. But that might just be me. :-\ -- Asbjørn Ulsberg -=|=-http://virtuelvis.com/quark/ «He's a loathsome offensive brute, yet I can't look away»
Re: Base URI and link rel=self
On Fri, 22 Apr 2005 09:06:56 +0200, Thomas Broyer [EMAIL PROTECTED] wrote: As said above, the base URI problem is not only an xml:base one... and it's not easy to solve... Well, actually it is. It's a huge camel to digest, but the solution is to require absolute URI's in all resource references in Atom. Perhaps we could combine this with requiring use of xml:base, but it should at least never be necessary to find the Atom document's base URI from the document's original location, because that location might change rapidly. -- Asbjørn Ulsberg -=|=-http://virtuelvis.com/quark/ «He's a loathsome offensive brute, yet I can't look away»
Using namespaces instead of 'type' (was: Re: HTML/XHTML type issues, was: FW: XML Directorate Reviewer Comments)
On Thu, 14 Apr 2005 23:58:05 +0200, Antone Roundy [EMAIL PROTECTED]
wrote:
atom:content type=XHTML xmlns:atom=our namespace URI xmlns=XHTML's
namespace URI
divThis is XHTML content,br /
and the default namespace is XHTML's./div
/atom:content
This example made me think about another solution for the Content
Constructs of Atom. Today, they all reside in the Atom namespace, which of
course, makes most sense. But even though I see it is a major hack, won't
putting Content Constructs inside the target namespace of the embedded
content be a solution to tell what type of content we are embedding
without having to use a 'type' element? Example:
feed xmlns=atom ns
...
content xmlns=http://www.w3.org/1999/xhtml;
h1Booyah! This is an XHTML fragment./h1
/content
/feed
Since Atom consumers need to have special handling for each 'type'
('html', 'xhtml', 'text') we provide today, we might as well imho signify
this with the XHTML namespace as with a 'type' attribute. The problem is
that it's difficult to say «this is to be parsed as escaped SGML» in
contrary to «this is to be read as plain text». Alas, we need a solution
for non-XML types in Atom if we think using namespaces is a good enough
solution for XML types.
If we take the hack even further, we could create pseudo namespaces for
text and HTML types as well. Or perhaps even a general SGML namespace. So
when we want to embed text in Content Constructs, we do it like this:
content xmlns=atom ns#text
*Booyah! This is an text fragment.*
/content
And when we want to embed HTML, we do it like this:
content xmlns=atom ns#html
lt;h1gt;Booyah! This is an text fragment.lt;/h1gt;
/content
I've already mentioned that I think this solution is a hack, and I'm not
sure I like it, but what I do like about it is that it gives us a general
way to deal with XML content that is much simpler (imho at least) than any
other previous solution (which have included 'type', 'mode' and various
other attributes).
Yes, there is no element called 'xhtml:content' in the XHTML
specification, but we won't have _valid_ (although wellformed) XHTML in
Atom anyways, so why strive so hard to reach something we won't reach
anyway? The XHTML content in Atom will be valid XML. It can't ever be
valid XHTML. Let's just settle with that and move forward, no?
--
Asbjørn Ulsberg -=|=-http://virtuelvis.com/quark/
«He's a loathsome offensive brute, yet I can't look away»
Re: HTML/XHTML type issues, was: FW: XML Directorate Reviewer Comments
On Wed, 13 Apr 2005 14:39:48 +0200, A. Pagaltzis [EMAIL PROTECTED] wrote: Multiple proposals already posted for the wording of this section suggestion a refererence to the XHTML 1.0 Transitional spec. That would seem to have preempted this problem. Do we really want to exclude XHTML 1.1 as allowed content in Atom documents? -- Asbjørn Ulsberg -=|=-http://virtuelvis.com/quark/ «He's a loathsome offensive brute, yet I can't look away»
Re: HTML/XHTML type issues, was: FW: XML Directorate Reviewer Comments
On Wed, 13 Apr 2005 08:08:42 +0200, Henri Sivonen [EMAIL PROTECTED] wrote: namely to use a Strict DOCTYPE. type='xhtml' takes a fragment and Atom is DTDless. Better to stay away from the word DOCTYPE. Of course. Still, the allowed elements and attribtues inside the div of Atom Content constructs is bound to the version of XHTML we choose. And the way to identify which version of XHTML you use happens to be done with a DOCTYPE and appurtenant DTD (and sadly not an XSD or similar), so I'm using it only as a way to identify which versions we are to use, not because I want the actual DOCTYPE construct to be allowed within an Atom document. And please note that I have not suggested any form of wording for this specification text yet, so this can be formulated however the group finds best. I have no proposals for specification text at the moment. -- Asbjørn Ulsberg -=|=-http://virtuelvis.com/quark/ «He's a loathsome offensive brute, yet I can't look away»
Re: HTML/XHTML type issues, was: FW: XML Directorate Reviewer Comments
On Wed, 13 Apr 2005 23:42:29 +0200, Robert Sayre [EMAIL PROTECTED] wrote: Real world example: [snip example] What do we have to say about this? As far as I can see, the code is valid XHTML 1.0 Strict (and thus also both Transitional, Frameset and XHTML 1.1), so I'm not sure what point you're making, Robert. Sure, the code is far from pretty, but the validity of it is okay. We can't demand validation or validity in any way, but we can and should encourage people to follow W3C's recommendations. And for a long time, they have been to code against the strictest DTD possible for the version of (X)HTML you are using. Transitional is a DTD to code against if you're transitioning from invalid DOCTYPE-less HTML or HTML 3.2 to valid HTML 4.01 Strict. XHTML 1.0 Transitional is a mistake, but that discussion is off topic, so I'll leave that for now. -- Asbjørn Ulsberg -=|=-http://virtuelvis.com/quark/ «He's a loathsome offensive brute, yet I can't look away»
Re: HTML/XHTML type issues, was: FW: XML Directorate Reviewer Comments
On Thu, 14 Apr 2005 05:37:42 +0200, Robert Sayre [EMAIL PROTECTED] wrote: Thank you, Asbjørn: this is a delightful little problem. You see, XHTML validity is specified in terms of DTDs. Near as I can tell, that example and some of the XHTML examples in the spec are 'invalid' because the local names don't match the DTD, and there are stray xmlns declarations. If any of the current versions of XHTML allow that, we should probably point to that one, but I don't know if any of them do. Ah, nice catch. Didn't even think about it, but you're right: Well-formed XML is not necessarily valid XHTML. What in the hay are we supposed to reference? That's a very good question I really wished I had an answer to. But right now, I don't. :-\ -- Asbjørn Ulsberg -=|=-http://virtuelvis.com/quark/ «He's a loathsome offensive brute, yet I can't look away»
Re: HTML/XHTML type issues, was: FW: XML Directorate Reviewer Comments
On Wed, 13 Apr 2005 00:02:48 +0200, Robert Sayre [EMAIL PROTECTED] wrote: How about this text for XHTML: If the value of type is xhtml, the content of the Text construct MUST be a single XHTML div element [XHTML transitional reference], and SHOULD be suitable for handling as XHTML. Good, but I would like us to have the same recommendations in the Atom specification as W3C, namely to use a Strict DOCTYPE. How to word this is still a bit blurred to me. -- Asbjørn Ulsberg -=|=-http://virtuelvis.com/quark/ «He's a loathsome offensive brute, yet I can't look away»
Re: HTML/XHTML type issues, was: FW: XML Directorate Reviewer Comments
On Tue, 12 Apr 2005 19:45:56 +0200, Henri Sivonen [EMAIL PROTECTED] wrote: But XHTML 2.0 is a different language form XHTML 1.x. Why do you think XHTML 2.0 fragments should be allowed as type='xhtml'? Just because XHTML 2.0 has XHTML in the name? Yes. If it is not about the name, why not DocBook NG fragments? Because DocBook does not have XHTML in its name, and will not under any circumstance cause confusion with Atom using the term XHTML as a type for content. Since XHTML 1.0 and 2.0 and most likely 2.1, 3.0 and whatnot will bear the names XHTML, we should allow all of them to be used in Atom. Or, we should restrict the allowed XHTML versions in the specification to just include 1.x. That leads to different problems, though, since people would then think they could use XHTML 1.0 Frameset or XHTML 1.1, which are totally different from one another, and will hurt interoperability a great deal. I'd say that we should limit the allowed XHTML versions (including both version number and DOCTYPEs) to be used in Atom to XHTML 1.0 Transitional, XHTML 1.0 Strict and XHTML 1.1. Since XHTML 2.0 isn't finished yet, it is a bit problematic including language about it in the Atom specification, so I think we should leave it out at least until it is done. Then we can patch Atom somehow with an I-D or whatever to include language about XHTML 2.0. -- Asbjørn Ulsberg -=|=-http://virtuelvis.com/quark/ «He's a loathsome offensive brute, yet I can't look away»
Re: PaceXhtmlNamespaceDiv posted
On Sun, 30 Jan 2005 18:43:18 +0100, Julian Reschke [EMAIL PROTECTED] wrote: For the record, I'm opposed to it, too. Same here. The spec is already saying this: The content SHOULD be XHTML text and markup that could validly appear directly within an xhtml:div element. ...so making it explicit in the on-the-wire format seems to be completely useless. Indeed. -- Asbjørn Ulsberg -=|=-http://virtuelvis.com/quark/ «He's a loathsome offensive brute, yet I can't look away»
Re: PaceXhtmlNamespaceDiv posted
On Sun, 30 Jan 2005 17:57:57 +, Graham [EMAIL PROTECTED] wrote: I'm in favor of it. My current parser doesn't let me pull out all childen of element x in one go, so I have to step through in a really hacky way. With this I can just grab the div. You can't grab 'atom:content/*[1]' or something similar? -- Asbjørn Ulsberg -=|=-http://virtuelvis.com/quark/ «He's a loathsome offensive brute, yet I can't look away»
Re: PaceOrderSpecAlphabetically
On Sun, 30 Jan 2005 12:34:42 -0500, Sam Ruby [EMAIL PROTECTED] wrote: Order the Element Definitions in the specification alphabetically. Sounds like a very good idea. +1. -- Asbjørn Ulsberg -=|=-http://virtuelvis.com/quark/ «He's a loathsome offensive brute, yet I can't look away»
Re: URI canonicalization
On Sun, 30 Jan 2005 14:06:49 -0500, Sam Ruby [EMAIL PROTECTED] wrote: We discussed this at extreme length, and no new arguments have been brought forward. Rough consensus does not mean absolute consensus. Thank you. We've discussed this too much already. Please let's leave this horse; it's already beaten to death and won't get any more dead no matter how much we keep on beating. -- Asbjørn Ulsberg -=|=-http://virtuelvis.com/quark/ «He's a loathsome offensive brute, yet I can't look away»
Re: PaceFormatSecurity
On Fri, 28 Jan 2005 17:01:06 -0500, Robert Sayre [EMAIL PROTECTED] wrote: I guess the question is whether we can and should outline HTML security issues. I don't think we can or should. Considering the large amount of (X)HTML that are being syndicated via RSS and Atom today and will be in the future, I think we should. (X)HTML will be the main markup used inside all Atom Text Constructs, and while MathML, SVG and other markup languages we don't know about may contain security issues, they aren't nearly as important to mention as those that lie within (X)HTML. -- Asbjørn Ulsberg -=|=-http://virtuelvis.com/quark/ «He's a loathsome offensive brute, yet I can't look away»
Re: PaceFormatSecurity
On Fri, 28 Jan 2005 13:21:08 -0800, Tim Bray [EMAIL PROTECTED] wrote: Whereas you could technically get by with warning-by-reference, I think that it's OK and fact probably essential to point out that img and script and object and so on; are potentially lethal; I agree. However, it is impossible to write a specification today about security issues we don't know of, but those we do know, like the elements you mention, should also be mentioned in the specification. I thought Joe got about the right level, except for the what to do stuff. Yep. If he leaves that out of the pace, I'm all +1 to it. -- Asbjørn Ulsberg -=|=-http://virtuelvis.com/quark/ «He's a loathsome offensive brute, yet I can't look away»
Re: PaceFormatSecurity
On Fri, 28 Jan 2005 17:13:26 -0800, Paul Hoffman [EMAIL PROTECTED] wrote: Many elements are consider 'unsafe' in that they open clients to one or more types of attack. Every client should consider carefully their handling of every type of element when processing incoming (X)HTML in Text Constructs. See the security sections of RFC 2854 and HTML 4.01 for some guidance on many type of attacks. Atom readers should pay particular attention to the security of the IMG, SCRIPT, EMBED, OBJECT FRAME, FRAMESET, IFRAME, META, LINK elements, but other elements may also have negative security properties. This reads well, imo. But I would replace «(X)HTML» with «markup» in the first paragraph, because there may be security issues with other markup languages as well. I would then rewrite the second paragraph like this: Atom readers should pay particular attention to the security of HTML and XHTML's IMG, SCRIPT, EMBED, OBJECT, FRAME, FRAMESET, IFRAME, META and LINK elements, but other elements may also have negative security properties. I'm having a bit problem with calling EMBED an HTML element, though, since no HTML standard includes it. -- Asbjørn Ulsberg -=|=-http://virtuelvis.com/quark/ «He's a loathsome offensive brute, yet I can't look away»
Re: PaceEnclosuresAndPix status
On Thu, 27 Jan 2005 22:12:41 +1100, Eric Scheid [EMAIL PROTECTED] wrote: http://www.intertwingly.net/wiki/pie/PaceIconAndImage Nice. But if we have both atom:icon and atom:image for the feed, why do we need to do all kinds of wierd stuff to have images attached to Atom entries? Can't atom:image (perhaps not atom:icon) occur as a child of atom:entry too? This competes with parts of PaceEnclosuresAndPix, and so have also written PaceLinkEnclosure which simply strips out the Pix part. Right. So we include images of the feed with 'image', while images for entries with 'link'. That doesn't make sense. It also doesn't make much sense to have several elements to do the exact same thing. My head is screaming for atom:object here. -- Asbjørn Ulsberg -=|=-http://virtuelvis.com/quark/ «He's a loathsome offensive brute, yet I can't look away»
Re: PaceFeedLink
On Wed, 26 Jan 2005 07:53:33 -0800, Tim Bray [EMAIL PROTECTED] wrote: Software which discovers that the FeedLink URI is different from that used to retrieve the atom:feed document containing MAY choose to use the FeedLink URI for subsequent fetches. Nicely put. +1. -- Asbjørn Ulsberg -=|=-http://virtuelvis.com/quark/ «He's a loathsome offensive brute, yet I can't look away»
Re: Questions about -04
On Wed, 26 Jan 2005 21:39:34 -0500, Sam Ruby [EMAIL PROTECTED] wrote: There are now, by some counts, ten versions of formats that call themselves RSS. Every last one of then has a required channel/link. Every last one of them. Yes. Relaxing a restriction requires consumers to handle more cases. How much does it cost for consumers to handle these cases compared to how much it restricts the producers? With this restriction, all Atom feeds needs to be a copy of another resource type. It can never be a first class resource. I think feed level alternative links are useful, but not more than that they need to be a SHOULD, not MUST. Because of this, I would like to request that there be a compelling use case be found which for feeds for which there can not be a atom:link defined. I would much rather require 'rel=self' than 'rel=alternate'. The former doesn't require anyone to double-produce anything, while the latter almost always requires people to have some kind of HTML representation of their feed lying around somewhere. If all the consumer and producer's interested in is the Atom feed, why would one need a secondary resource that the feed can point to? I cannot understand why the alternative HTML page is needed. If people mystically and by mere coincidence subscribe to a feed without an alternate resource in their aggregator, how can this hurt anyone? The will be subscribed, have all the entries show up in their aggregators, but not be able to view the feed in another format. Note atom:link is defined as a URI. While most examples that we have seen use the HTTP scheme, this is not a requirement. No, but we've also seen that most other schemes are totally useless in practice. What should an aggregator do with a 'news' scheme, for instance? What about 'prospero'? What about proprietary schemes that aren't registered in IANA and only retreivable through some sort of direct TCP socket? We have lots of these inside the Norwegian Broadcasting Corporation; we are an old publisher and broadcaster. I do not see why we (or anyone else) should be required to publish all the content we wish to syndicate to users, other companies and such, in alternative formats to Atom, just because the Atom specificatino requires it. If we don't do it to please our users, I don't see why we should do it at all. Just to comply with a specification is imho not a good enough reason. -- Asbjørn Ulsberg -=|=-http://virtuelvis.com/quark/ «He's a loathsome offensive brute, yet I can't look away»
Re: PaceEnclosuresAndPix status
On Sat, 29 Jan 2005 16:47:09 +1100, Eric Scheid [EMAIL PROTECTED] wrote: Maybe image is the wrong name for the concept. We're not talking about some random image associated with some entity, we're talking about a branding badge or logo of some kind which is representative of the feed. I know what we're talking about and still don't understand why embedding so-called «favorite icons» is so wildely different from embedding other types of graphical objects in feeds (at all levels) that it has to be done in a wildely different way. We're trying to create a mechanism for embedding graphics, and in some cases the graphic has special meaning. Then let's of course assert that special meaning, but not by creating several completely different mechanisms for embedding graphics in Atom feeds! While entries may well have images of various kinds attached to them (cat pictures, anyone?), the individual entries don't get branded with their own logo/badge, do they? If they do, that's none of our (or at least my) business. If people want icons for their entries, let them have it. If aggregator writers want to add support for bookmarking individual entries (it makes sense, doesn't it?), it would be a lot easier to find these entries later on if they had some kind of icon attached to them. That icon could of course be the same as the feed's, but it could also be something completely different. The point is that if we have a general way of embedding graphical objects in Atom feeds, we don't need to differ between feed- and entry-level graphics. We only need to define some types of graphical objects that have special meaning so they can be treated specially by aggregators. One such graphical object is «icon». It is an embedded graphical object, but it's supposed to be shown in a special place in the aggregator. Hmmm... maybe I'll rename it to atom:logo ... would that help? If the renamed element can be used to embed all sorts of graphical objects in both feeds and entries; yes. :) -- Asbjørn Ulsberg -=|=-http://virtuelvis.com/quark/ «He's a loathsome offensive brute, yet I can't look away»
Re: Difference of TEXT and XHTML?
On Wed, 26 Jan 2005 17:03:09 -1000 (HST), Lucas Gonze [EMAIL PROTECTED] wrote: Then my point is moot as long as XHTML inline content may be XHTML 1.0 Transitional. A second argument that inline XHTML may be XHTML 1.0 Transitional is that it satisfies the need for well-formed XML. You do whatever you please, of course, but HTML and XHTML is not supposed to be used for formatting, but for structure and semantics. That's why font et al has been dropped from XHTML 1.1, 2.0 and the Strict DTD's (which is recommended to use over the Transitional ones). Because having control over presentation is the main reason to format content as HTML. Uhm. Okay. -- Asbjørn Ulsberg -=|=-http://virtuelvis.com/quark/ «He's a loathsome offensive brute, yet I can't look away»
Re: Issues with draft-ietf-atompub-format-04
On Tue, 25 Jan 2005 09:59:08 +0100, Anne van Kesteren [EMAIL PROTECTED] wrote: This was about it. I hope it is of some use. I share all your concerns and issues and hope they will be addressed properly before the format is finalized. -- Asbjørn Ulsberg -=|=-http://virtuelvis.com/quark/ «He's a loathsome offensive brute, yet I can't look away»
Re: PaceDateUpdated2 status
On Tue, 25 Jan 2005 13:28:36 +1100, Eric Scheid [EMAIL PROTECTED] wrote: Did someone do a survey of what date concepts the various blog publishing systems support? Yes: url: http://intertwingly.net/wiki/pie/BlogToolDateSurvey -- Asbjørn Ulsberg -=|=-http://virtuelvis.com/quark/ «He's a loathsome offensive brute, yet I can't look away»
Re: PaceAttributesNamespace status
On Tue, 25 Jan 2005 10:07:05 -0500, Sam Ruby [EMAIL PROTECTED] wrote: 2. It's not clear how you'd pepper atom elements with attributes (ie do we spec that you must put your extra attribs in a namespace?). This should be made clearer. What I would suggest (for the spec'ed XML serialization) is that adding attributes to atom elements is OK if and only if they are in a namespace other than or atom's. +1. Some language describing this should go into the specification. I hope we don't need a pace to cover that. 4. it's not clear whether atom prefixed attributes are allowed or acceptable. Is it one or the other? Both? Such attributes are not equivalent to the spec'ed attributes, so the expectation would be that they would be ignored. I would support making this clearer per my comment to #2. I agree. I also think we should keep «Atom attributes» (although not in the Atom namespace) unprefixed and un-namespaced to have the format look cleaner and more readable. That doesn't mean that ':href' is the same as 'atom:href', though. Thus, I'm -1 on this pace, but +1 on making the spec clearer about these issues. -- Asbjørn Ulsberg -=|=-http://virtuelvis.com/quark/ «He's a loathsome offensive brute, yet I can't look away»
Re: PaceEntriesAllTheWayDown status
On Mon, 24 Jan 2005 16:17:48 -0800, Tim Bray [EMAIL PROTECTED] wrote: If there were no further discussion: This is a radical change to the document and, so far, hasn't gathered widespread enough support to make it over the line. -Tim I haven't seen it before, but think it's a nice proposal. I don't see the big (bad) implications it has on the spec or implementations of it; if anything, it should make it easier to read the specification and parse and generate Atom documents. +1. -- Asbjørn Ulsberg -=|=-http://virtuelvis.com/quark/ «He's a loathsome offensive brute, yet I can't look away»
Re: PaceMustBeWellFormed status
On Mon, 24 Jan 2005 16:17:40 -0800, Tim Bray [EMAIL PROTECTED] wrote: If there were no further discussion: The WG completely failed to converge to consensus on these issues last time around. Consensus can still be found here. -Tim I think we should do something about it, if we don't incorporate it into the specification. I like it very much. -- Asbjørn Ulsberg -=|=-http://virtuelvis.com/quark/ «He's a loathsome offensive brute, yet I can't look away»
Re: PaceSyntaxGuidelines status
On Tue, 25 Jan 2005 14:37:56 -0500, Robert Sayre [EMAIL PROTECTED] wrote: Asbjørn, I can sympathize with the goal, but it's not appropriate to include in the spec. It's babysitting. I kind of agree. If the mythical Implementor's Guide were to materialize, it might make a good home for this text. Let's wait for it and see, then. I think we're facing a long time of waiting, though. -- Asbjørn Ulsberg -=|=-http://virtuelvis.com/quark/ «He's a loathsome offensive brute, yet I can't look away»
Re: content for text/ or +xml SHOULD be local? (was: Re: Hash for Links)
On Tue, 11 Jan 2005 16:46:35 +0900, Martin Duerst [EMAIL PROTECTED] wrote: If the value of type begins with text/ or ends with +xml, the content SHOULD be local; that is to say, no src attribute should be provided. When I read this, I was somewhat surprised to find a SHOULD. A should, in IETF terms, is really quite strong. I'd prefer a wording such as: In general, content with value of type beginning with text/ or ending with +xml will be inline; that is to say, no src attribute is provided. I'm fine with both wordings, but: In both cases, adding something like Such content is usually short, and in that case, carrying it inline is more efficient. covers the rationale I know about. There may be other rationales. - I think the word 'inline' is much better than 'local'. So no matter which wording is used in the specification, the content should be 'inline', not 'local'. -- Asbjørn Ulsberg -=|=-http://virtuelvis.com/quark/ «He's a loathsome offensive brute, yet I can't look away»
Re: Revisiting feed discovery
On Fri, 21 Jan 2005 17:35:05 +1100, Eric Scheid [EMAIL PROTECTED] wrote: How is a resource which shows the last 15 entries as of today an alternative representation of an entry which was published six months ago and has long slipped out of the sliding window? It isn't, and that's not what I meant. I think 'alternate' links are being overloaded with these kinds of meanings all the time; e.g. individual HTML pages pointing to the feed in which they occur as RSS items as 'alternate'. That's wrong and I agree that we should have another type of link relation for those links. But I'm not sure 'feed' is the correct one. Its not the best word, but others which are better are already taken for other purposes (eg source, origin, etc), or are clumsy word-pairs which are still not properly indicative of the ongoing publishing nature (eg. DC's part-of). I think 'part-of' is better. It's a relation and describes accurately what the link is pointing to. In the feed one could even have 'rev' links to go the other way, although that isn't necessary. -- Asbjørn Ulsberg -=|=-http://virtuelvis.com/quark/ «He's a loathsome offensive brute, yet I can't look away»
Re: Questions about -04
On Wed, 12 Jan 2005 16:54:27 -0500, Sam Ruby [EMAIL PROTECTED] wrote: 2. Why MUST a feed point to an alternate version. What if the feed is all I publish? Deja vu: http://www.imc.org/atom-syntax/mail-archive/msg08836.html I think this goes along with the alternate entry discussion which ended up in these paces: url: http://www.intertwingly.net/wiki/pie/PaceContentOrLink url: http://www.intertwingly.net/wiki/pie/PaceOptionalAlternateLink I'm -1 on removing this restriction. I think alternate links for both entries and feeds should be optional, but I'm more eager to have it be optional for entries. -- Asbjørn Ulsberg -=|=-http://virtuelvis.com/quark/ «He's a loathsome offensive brute, yet I can't look away»
Re: PaceIRI
On Tue, 11 Jan 2005 16:04:16 +0900, Martin Duerst [EMAIL PROTECTED] wrote: I have completed (as far as I'm concerned) PaceIRI. Looks good, but I dislike this point: «Do *not* replace element/attribute names that read 'uri'. This will lead to somewhat strange sentences as The content of atom:uri in a Person construct MUST be a IRI. While this makes the spec somewhat strange to read in very few places, it will work out for users.» I think all the 'uri' elements and attributes should jump on the next train to '/dev/null' and be replaced with 'href', ordinary Link Constructs or whatever. They stick out from the specification like dobermans in a duck-pond and just feels awkward and «not right». With the introduction of IRI's, I think they are even more misplaced and there's better reasons for us to remove them completely. -- Asbjørn Ulsberg -=|=-http://virtuelvis.com/quark/ «He's a loathsome offensive brute, yet I can't look away»
Re: The Atom Format end-game
On Thu, 6 Jan 2005 21:17:41 -0700, Antone Roundy [EMAIL PROTECTED] wrote: While permanent, universally unique identifier might perhaps be a bit too terse, an identifier that is used to associate different instances of the same resource. Whenever a resource appears in an Atom Document, its identifier SHOULD be the same as any other times it has appeared in an Atom Document, and MUST NOT be the same as the identifier currently or formerly used for any other Atom resource may be a bit longer than is necessary. Indeed. I think making the distinction between the Atom entry and the resource that it conveys information about introduces unnecessary verbosity to the language. I agree. An Identity construct is an element whose content conveys a permanent, universally unique identifier for its parent element. Permanent means that the its content MUST NOT change when the parent element or any element or document containing it is retransmitted, revised, relocated, migrated, syndicated, republished, exported or imported. Universally unique means that its content cannot have been used as the identifier for any other element in any Atom document. Its content MUST be an absolute URI [RFC2396]. Instead of «its content», I think «the identifier» is better. Thus: «Universally unique means that the identifier cannot have been used as the identifier for any other element in any Atom document». -- Asbjørn Ulsberg -=|=-http://virtuelvis.com/quark/ «He's a loathsome offensive brute, yet I can't look away»
