Re: Autodiscovery Draft
On Mon, 19 Mar 2007 23:00:34 +0100, John Panzer [EMAIL PROTECTED] wrote: There were strong suggestions at the time, I think, that this was part of HTML and should belong to the WHAT-WG. So is there a WHAT-WG document to look at? http://www.whatwg.org/specs/web-apps/current-work/#linkTypes -- Anne van Kesteren http://annevankesteren.nl/ http://www.opera.com/
Re: base within HTML content
On Tue, 02 Jan 2007 01:21:09 +0100, Henri Sivonen [EMAIL PROTECTED] wrote: I suppose you could raise this on the WHATWG list. Asking what happens if you set innerHTML of a div where the setted value has both a base and an a for instance. Interesting. I hadn't thought that Atom was supposed to use innerHTML parsing. I'd have said that you prepend !DOCTYPE htmltitle/ titlediv to what travels in the feed and append /div to it, parse the resulting string and grab the first div in the document order. That could work as well. In that case base would most certainly apply. But nothing like that is defined... -- Anne van Kesteren http://annevankesteren.nl/ http://www.opera.com/
Re: base within HTML content
On Tue, 02 Jan 2007 02:12:14 +0100, James Holderness [EMAIL PROTECTED] wrote: Well that's not really what I've learnt. I've learnt that there are a lot of broken feeds out there (Atom as well as RSS) and that users are less than impressed when you tell them it's not your fault and they should complain to someone else. So if a feed is non-well-formed you should just parse it as well using some tag soup parser for XML? I don't necessarily disagree with that, but I'd like error handling to be defined in great detail. Everyone just doing what is best for their users will lead you to where HTML is now (at best). -- Anne van Kesteren http://annevankesteren.nl/ http://www.opera.com/
Re: base within HTML content
On Tue, 02 Jan 2007 11:40:53 +0100, A. Pagaltzis [EMAIL PROTECTED] wrote: * Henri Sivonen [EMAIL PROTECTED] [2007-01-02 01:35]: I hadn't thought that Atom was supposed to use innerHTML parsing. I'd have said that you prepend !DOCTYPE htmltitle/titlediv to what travels in the feed and append /div to it, parse the resulting string and grab the first div in the document order. That will lead to silent data loss if the content is malformed such that it contains an extraneous `/div`. Yeah, it's probably better to take the first and only body element. -- Anne van Kesteren http://annevankesteren.nl/ http://www.opera.com/
Re: base within HTML content
On Mon, 01 Jan 2007 21:22:33 +0100, Geoffrey Sneddon [EMAIL PROTECTED] wrote: If you want a local base, then use xml:base. That's what it is for. When the spec says you SHOULD treat html content as if it were in a DIV, it adds a certain amount of unclarity as how such Atom feeds should be parsed. I'm asking merely to see if there's any consensus as to how it should be done. I have no control over the vast majority of feeds out there - telling me to use xml:base will make no difference, as I have no control over the feed in which I found a base. Hmm, the same is true for a large number of other cases. Atom in general is ambigious at best in terms of error handling. I suppose you could raise this on the WHATWG list. Asking what happens if you set innerHTML of a div where the setted value has both a base and an a for instance. -- Anne van Kesteren http://annevankesteren.nl/ http://www.opera.com/
Re: Text-type contents and White Space
On Sat, 30 Dec 2006 11:03:56 +0100, Franklin Tse [EMAIL PROTECTED] wrote: IE and Firefox both failed to display text/plain contents. Opera can but all white space was collasped I suppose that's something we should fix then. * files a bug report. -- Anne van Kesteren http://annevankesteren.nl/ http://www.opera.com/
Re: Text-type contents and White Space
On Sat, 30 Dec 2006 11:33:32 +0100, Franklin Tse [EMAIL PROTECTED] wrote: I have tested with both atom:content type=text/plain and atom:content type=text/plain xml:space=preserve. I don't think we do anything with xml:space. The definition it has makes it kind of pointless I think. -- Anne van Kesteren http://annevankesteren.nl/ http://www.opera.com/
Re: Atom Entry docs
On Fri, 15 Dec 2006 13:43:58 +0100, A. Pagaltzis [EMAIL PROTECTED] wrote: 1) Define ;type=feed and ;type=entry as optional parameters. (i.e. get them defined, registered, and ready to use.) 2) Leave RFC4287 unchanged. i.e. do NOT re-define application/atom-xml 3) New specifications MAY require that ;type=entry be used. (Note: Just because ;type=entry is used DOES NOT imply that ;type=feed must also be used) +1 Did anyone check how widely deployed the entry documents actually are? And how much support there is for them? -- Anne van Kesteren http://annevankesteren.nl/ http://www.opera.com/
Re: Atom namespace really not ending with / or # ?
On Tue, 12 Dec 2006 08:18:49 +0100, Jan Algermissen [EMAIL PROTECTED] wrote: is it really true that the Atom namespace is http://www.w3.org/2005/Atom ? Yes. Meaning that it is somewhat difficult to identify Atom elements with URIs: http://www.w3.org/2005/Atomauthor http://www.w3.org/2005/Atomconributor Isn't that only relevant for RDF vocabularies? Was that simply a mistake or a design feature when Atom was standardized? It wasn't really relevant, I'd say. (That it says Atom and not atom was a mistake.) -- Anne van Kesteren http://annevankesteren.nl/ http://www.opera.com/
Re: PaceMakeAutodiscoveryInformational
On Tue, 28 Nov 2006 17:37:03 +0100, James M Snell [EMAIL PROTECTED] wrote: == Proposal == Change the status of the autodiscovery draft to Informational. +1 -- Anne van Kesteren http://annevankesteren.nl/ http://www.opera.com/
Re: Atom and bidi
On Tue, 03 Oct 2006 04:03:50 +0200, Eric Scheid [EMAIL PROTECTED] wrote: what happens with content src=.. dir=rtl / ? The same as with xht:object data= dir=rtl/ ... (Please don't ask the obvious question, it's probably not defined.) -- Anne van Kesteren http://annevankesteren.nl/ http://www.opera.com/
Re: Atom and bidi
On Tue, 03 Oct 2006 17:03:02 +0200, James M Snell [EMAIL PROTECTED] wrote: huh? REC-xml-2.12: The language specified by xml:lang applies to the element where it is specified (including the values of its attributes), and to all elements in its content unless overridden with another instance of xml:lang. Your point being? -- Anne van Kesteren http://annevankesteren.nl/ http://www.opera.com/
Re: Does xml:base apply to type=html content?
Quoting A. Pagaltzis [EMAIL PROTECTED]: * James Holderness [EMAIL PROTECTED] [2006-04-04 03:25]: The way I see it, until a standards body tells us otherwise, we are obliged to support the Content-Location header unless we can provide a very good argument for ignoring it. +1, standards aren’t there for people to cherry-pick the parts they find convenient or useful. If interoperable implementations for standards are not possible, they are useless. The goal of having standards is interoperable implementations. Opera has removed support for Content-Location (or least partially, not sure of the details) for the same reasons as Firefox. (This also isn't really about convenient or useful...) -- Anne van Kesteren http://annevankesteren.nl/
Re: Does xml:base apply to type=html content?
Quoting James Holderness [EMAIL PROTECTED]: I think the issue of neutral link bookmarking is unlikely to be a problem for Atom aggregators though. Server bugs are another thing, but I think most feeds will be broken without an explicit xml:base anyway, so maybe that's not worth worrying about. I'm not sure though. Should the WG recommend ignoring Content-Location as a base URI, or should aggregators follow the RFC exactly as specified? If `Content-Location` is not usable or can't be used consistent on a website (for example, using it for both Atom and HTML content) I suggest we specify something that is consistent with what browsers do. And perhaps try to obsolete the relevant header if possible... -- Anne van Kesteren http://annevankesteren.nl/
Re: Does xml:base apply to type=html content?
Quoting A. Pagaltzis [EMAIL PROTECTED]: * David Powell [EMAIL PROTECTED] [2006-03-31 09:55]: XHTML 1.0 doesn't support xml:base does it? As I understand it, only specs that say that they support xml:base allow you to put xml:base on their elements, but any spec that allows URIrefs has the concept of a base-URI, so for envelope specs such as Atom, you'd expect xml:base in the envelope to set the base-URI for the content. To be honest, I’m not sure about the precise spec interactions for this case. What I do know however is that Gecko respects xml:base in XHTML content. Opera 9 weeklies should do the same... -- Anne van Kesteren http://annevankesteren.nl/
Re: atom:name ... text or html?
Quoting Eric Scheid [EMAIL PROTECTED]: If I have an author with the name Bertrand Café, is it acceptable to put that into atom:author like this; authorname![CDATA[Bertrand Cafeacute;]]/name/author or should I be using the unicode numeric entity instead? Even if it was HTML you couldn't really use the entity, could you? I think you have to use a character reference or the actual character instead, yes. -- Anne van Kesteren http://annevankesteren.nl/
Re: Atom logo where?
Quoting Tim Bray [EMAIL PROTECTED]: Where can one go to get versions of the atom logo (the one in view at atomenabled.org) in various sizes? -Tim I guess SVG fits that definition: http://zcorpan.1go.dk/sandbox/svg/atom/.xml -- Anne van Kesteren http://annevankesteren.nl/
Re: Browser behaviour
Quoting Danny Ayers [EMAIL PROTECTED]: The mail below is from the WordPress list, they're discussing including stylesheet references in Atom docs. Have we got anything like best practices or more palatable workarounds for these circumstances? (i.e. in addition to using application/atom+xml) The least they could do is use application/xml. (I'm using that at the moment...) For the rest, bug browser people about it. Opera, for one, parses everything +xml as XML. -- Anne van Kesteren http://annevankesteren.nl/
Re: new draft? (was: invention)
Quoting Thomas Broyer [EMAIL PROTECTED]: Why not use the media attribute? Because that would be tag abuse. -- Anne van Kesteren http://annevankesteren.nl/
Re: finishing autodiscovery, like now
Quoting Eric Scheid [EMAIL PROTECTED]: On 20/1/06 5:13 AM, A. Pagaltzis [EMAIL PROTECTED] wrote: But we already have a name for doing that: it¹s called ³linking to something.² Now, it¹d be useful to encourage people to add `type` attributes to their `a` links, so tools could find them just by looking at the page without spidering. But `rel` does not add any information. Here is a link to a resource: link type=application/atom+xml href=... / Please explain how a tool can decide whether that is a link to a atom:feed document, or is a link to an atom:entry document? Why is that relevant? -- Anne van Kesteren http://annevankesteren.nl/
Re: ACE - Atom Common Extensions Namespace
Quoting James M Snell [EMAIL PROTECTED]: The Atom Common Extensions Namespace http://www.w3.org/2005/Atom/ace; It should probably be something like http://www.w3.org/2005/Atom-extensions Having a file and folder of the same name is not technically possible. (Although you could emulate the effect of course with some mod_rewrite.) The idea seems nice though. Less namespaces for people to learn seems like a good thing. -- Anne van Kesteren http://annevankesteren.nl/
Re: ACE - Atom Common Extensions Namespace
Quoting A. Pagaltzis [EMAIL PROTECTED]: No, I mean an element name prefix. So f.ex. your indexing extension would have all its elements start with “idx-” or “x-” or something whereas the comments one would use “thr-” maybe. It is either namespaces or this. As we have namespaces, we should not do this. -- Anne van Kesteren http://annevankesteren.nl/
[feedvalidator] amp;apos; is not HTML
Hi, I could not find the e-mail address from Sam Ruby that fast so I thought I would e-mail the list. http://feedvalidator.org/check.cgi?url=http%3A%2F%2Fannevankesteren.nl%2Ffeeds%2Fhref As Atom 0.3 is deprecated I thought I would update my feeds. As I did not use anything fancy it was fairly trivial to do only I encountered this bug in the validator. I assume it was added to sniff for 'HTML like constructs' only this time the subject really was apos; and it was not used to double escape for HTML. Besides that, apos; is not even a valid entity for HTML 4. Kind regards, Anne -- Anne van Kesteren http://annevankesteren.nl/
Re: The Atomic age
Quoting Tim Bray [EMAIL PROTECTED]: Paul assures me that the remaining IETF process steps will not introduce material technical changes, and so format-10 is appropriate as a basis for implementors to go to work. So, implementors... to work. And everyone, now is a good time to tell the world. -Tim Yay! (Except for the namespace that is. Ouch!) -- Anne van Kesteren http://annevankesteren.nl/
Re: some small comments on 08
Robert Sayre wrote:
What happens when it does contain child elements? I think we should
define that for interoperability. (See HTML for what happens when
you don't.) This question also applies to the next section.
No, that's broken. There can be no expectation of interoperability.
I think there should be. Authors will try to do it anyway and defined
error handling is better than reverse engineering the market leader's
error handling.
For white-space significance text I need to use 'html' or 'xhtml'
instead using PRE or xhtml:pre?
I don't understand what you're saying here, but I'm pretty sure every
possible whitespace issue has been debated by Graham, Paul, Martin,
etc. Feel free to try and explain this again if I don't get it.
White-space may be collapsed inside 'text' as currently defined.
* 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.
* Links
I don't understand why we have so many different link constructs.
atom:link href=iri/, atom:imageiri/atom:image,
atom:uriiri/atom:uri, atom:content src=iri/.
Can't we name them consistently? I'd suggest 'href' or 'url'.
('url' is used in CSS and extensions of HTML and XHTML 1 made by
the WHATWG.)
Nope. Too late.
And this.
--
Anne van Kesteren
http://annevankesteren.nl/
Re: Author and contributor
A. Pagaltzis wrote: In [EMAIL PROTECTED] (http://www.imc.org/atom-syntax/mail-archive/msg15517.html), Antone Roundy suggests: make atom:author plural keep atom:contributor punt bylines to an extension To me that sounds like the simplest thing that can possibly work, and looks like it hits the 80/20 mark. It also requires the least squabbling over its implementation. And Robert has expressed that he is fine with the proposal in that thread. Ive expressed an affinity for the idea of putting atom:category in atom:contributor, but I see a lot of potential delay in that and no pressing need for it. Again, +1 to Antones suggestion. +1. -- Anne van Kesteren http://annevankesteren.nl/
Re: 4.2.7.1 Comparing atom:id
Robert Sayre wrote: I think the last paragraph of RFC3987, section 5.1 already says that :) http://rfc.net/rfc3987.html#s5.1. That also says that fragment components should be excluded. Is that true for Atom? Are we going to refer to that specification and that section from 4.2.7.1 in a future draft? -- Anne van Kesteren http://annevankesteren.nl/
Re: 4.2.7.1 Comparing atom:id
Robert Sayre wrote: I think the last paragraph of RFC3987, section 5.1 already says that :) http://rfc.net/rfc3987.html#s5.1. That also says that fragment components should be excluded. Is that true for Atom? Where does is say that? Sorry about that. I should read better before sending in questions. As you've probably noticed I referred to paragraph three of that section, but it talks about network retrieval. Paragraph four really applies to what we are talking about here... -- Anne van Kesteren http://annevankesteren.nl/
Re: atom:modified : Reducing the cruft
David Powell wrote: I detect that a lot of opposition to atom:modified comes from the fact that it is a REQUIRED element and that many of the publishers actually putting it in the feed and paying for the bandwidth don't intend using it frequently? Would it help if we said that if the atom:modified element is absent, its value MAY be taken from the atom:updated element? (or to put it another way: atom:modified MAY be omitted if its value is equivalent to the value of atom:updated). I think this will result in people misusing the field. Either giving atom:updated the last modified time or giving it the last significant modification time and simply omitting atom:modified because that is extra work. If it is introduced in some optional fashion it should not relate to another date construct I think. -- Anne van Kesteren http://annevankesteren.nl/
Re: Fetch me an author. Now, fetch me another author.
Thomas Broyer wrote: +1 on allowing multiple atom:author -1 to dropping atom:contributor -1 to renaming atom:author +1 to that. -- Anne van Kesteren http://annevankesteren.nl/
4.2.7.1 Comparing atom:id
http://atompub.org/2005/04/18/draft-ietf-atompub-format-08.html#rfc.section.4.2.7.1 I was wondering about: # Likewise, # # http://www.example.com/~bob # http://www.example.com/%7ebob # http://www.example.com/%7Ebob # # are three distinct identifiers, because IRI %-escaping is significant # for the purposes of comparison. s/significant/insignificant/? -- Anne van Kesteren http://annevankesteren.nl/
Re: 4.2.7.1 Comparing atom:id
Anne van Kesteren wrote: http://atompub.org/2005/04/18/draft-ietf-atompub-format-08.html#rfc.section.4.2.7.1 I was wondering about: # Likewise, # # http://www.example.com/~bob # http://www.example.com/%7ebob # http://www.example.com/%7Ebob # # are three distinct identifiers, because IRI %-escaping is significant # for the purposes of comparison. s/significant/insignificant/? I see I might have misinterpreted the prose. If so, I think it is not very clear. Can't we just say something that atom:id IRIs MUST NOT be normalized? -- Anne van Kesteren http://annevankesteren.nl/
Re: Autodiscovery paces
Nikolas Coukouma wrote: http://www.intertwingly.net/wiki/pie/PaceAnchorSupport +1 with the same remark as Mark Pilgrim. http://www.intertwingly.net/wiki/pie/PaceDifferentRelValue +1 if it is extended to support alternate as well when the feed really is the alternate version of the page. That would be a requirement for page authors. Feed readers don't have to check that and can fetch every feed with either a feed or alternate REL attribute value. -- Anne van Kesteren http://annevankesteren.nl/
Re: Autodiscovery paces
Robert Sayre wrote: http://www.intertwingly.net/wiki/pie/PaceDifferentRelValue +1 if it is extended to support alternate as well when the feed really is the alternate version of the page. That would be a requirement for page authors. Feed readers don't have to check that and can fetch every feed with either a feed or alternate REL attribute value. I don't understand what the feed relation indicates. What benefit does it have over a href=... type=application/atom+xml.../a ? That it can be used for *any* feed regardless its MIME type. Another advantage is that I can say: 'Look, an a href=link type=application/atom+xmlAtom feed/a that is well-formed', without making feed readers discover it. -- Anne van Kesteren http://annevankesteren.nl/
Re: Atom 1.0?
Walter Underwood wrote: If we choose a specific name, it *must* be in the RFC. Because the RFC must be a hit for that search. We can Google-bomb that string I guess. (Atom 1.0.) -- Anne van Kesteren http://annevankesteren.nl/
Re: Which is the preferred feed?
Bob Wyman wrote: Some sites are beginning to serve their feeds via intermediaries like FeedBurner. They are doing this, in part, to make it easier for them to get better statistics on their use of the feeds, to off-load bandwidth requirements, or to take advantage of the advertising insertion and management programs of the intermediaries. Sites could also use a HTTP 302 link on their own site that points to FeedBurner in the end. When FeedBurner dies or when they no longer have desire to use the service, they switch the location of the temporary redirect and all is fine. -- Anne van Kesteren http://annevankesteren.nl/
Re: Which is the preferred feed?
Antone Roundy wrote: 302 would result in feed readers (that follow the HTTP spec) continuing to hit the publisher's site every time they checked the feed, and then going to FeedBurner. As it would not be a very large hit of say, 25 to 50 KiB; I guess people can live with that. 2) Not everyone is going to be able to send a 302. Not everyone is going to be able to send 410 either. Not everyone is going to be able to say that the MIME type is application/atom+xml (yes, I'm aware about the deal with Apache and Microsoft). Et cetera. -- Anne van Kesteren http://annevankesteren.nl/
Re: Atom Implementation Guide: seeking co-editor
wrote: Tim at a time into my inbox earlier than the above: Given the volume of debate, it's obvious there may be more work to do here. Paul and I have asked Phil Ringnalda to co-edit the autodiscovery spec, and he's accepted. Crossed wires? Euh, the autodiscovery specification is not really equal to the implementation guide. -- Anne van Kesteren http://annevankesteren.nl/
Re: AutoDiscovery
Randy Charles Morin wrote: +1 to adding lang as an attribute to link thanks Robert link lang='en' ... The HTML and XHTML specification already define that. -- Anne van Kesteren http://annevankesteren.nl/
hreflang attribute should be allowed to be empty as well
I think that the HREFLANG attribute[1] should be allowed to be empty as well, just like xml:lang is allowed to be empty. [1]http://atompub.org/2005/04/18/draft-ietf-atompub-format-08.html#rfc.section.4.2.9.4 -- Anne van Kesteren http://annevankesteren.nl/
Re: suggestion: mention about xml:id
Domel wrote: Many case. Two examples: 1. Selectros in CSS. Now selectors can only be element like * , E, E F, E F and pseudo-class/pseudo-elements like: E:first-child. But we can't matche any E element ID. Atom 0.8 support xml:lang so support also E:lang(c) but there aren't any id attributes to CSS 's E#myid Perhaps I should have been more specific. What is the use case of styling Atom? 2. XPointers - point some parto of document in URI/IRI for example: http://example.org/atom.xml#myid Also, what is the use case for this. What should it actually when given to a feed reader. Note also that you can safely add the xml:id attribute to any element without causing any harm. It might be that the feed validator dislikes it, but that should't be a problem. -- Anne van Kesteren http://annevankesteren.nl/
Re: suggestion: add new value to type attribute
Brett Lindsley wrote: My thought on this was to treat an embedded XML document as a block of escaped text and let a processor other than the Atom processor handle it. Thus, text/plain, text/html and application/xhtml+xml ;-) would all be processed consistently (as a block of escaped text). Special case handling (XML docs) would be done outside of the Atom parser without a need to worry about the Atom context. XHTML is not escaped text and should not be treated as such imho. -- Anne van Kesteren http://annevankesteren.nl/
Re: suggestion: add new value to type attribute
James Aylett wrote: (Assuming text is an acceptable root element for SVG.) It isn't. application/xml is probably more appropriate. -- Anne van Kesteren http://annevankesteren.nl/
Re: xml:base and html rendering
Robert Sayre wrote: No, the thing is these two are similar problems structurally insofar as processing directives from the Atom layer are bleeding into the content. No. xml:base doesn't mean anything in (x)html, ever, so there is no need for a structural measure. Additional spec text wouldn't be adding requirements, just spelling out what's implied by our references. XHTML2 has xml:base and Mozilla for example supports xml:base in XHTML documents. -- Anne van Kesteren http://annevankesteren.nl/
Re: How should this be rendered?
Thomas Broyer wrote: (or any element using the CSS white-space property) That is purely for presentation. You should not use it if you need whitespace to be preserverd for semantics. (In such cases xml:space would probably be more appropriate...) -- Anne van Kesteren http://annevankesteren.nl/
Re: HTML/XHTML type issues, was: FW: XML Directorate Reviewer Comments
Norman Walsh wrote: / Anne van Kesteren [EMAIL PROTECTED] was heard to say: | Norman Walsh wrote: | But I hope not. I don't really want to have to rev the Atom format | spec when XHTML 2.0 comes out. With care, I want to just put XHTML 2.0 | stuff in my xhtml:div elements and let the down-stream appliation work | it out. | | XHTML 2 does have a different namespace. Ouch. I had forgotten or failed to notice that. Yeah, using namespaces for versioning sucks... | Future versions of XHTML may | or may not have a DIV element. In theory, sure, but in practice? HTML isn't likely to lose the element with the local-name div is it, really? Ask Ian Hickson. I believe he is planning to drop it in the WHATWG version of XHTML. | Also, what do you expect feed readers to support for XHTML versions, etc. I don't have any. I'll tailor my content to suit what the major vendors support, just like I do with my plain old HTML today. In practice, my feeds contain no markup at all (because I'm still generating RSS and I will not produce escaped markup). I don't really like this point of view. This is exactly what creates interoperability problems and people will blame Atom in the end for promising to solve problems it does not. -- Anne van Kesteren http://annevankesteren.nl/
Re: HTML/XHTML type issues, was: FW: XML Directorate Reviewer Comments
Norman Walsh wrote: But I hope not. I don't really want to have to rev the Atom format spec when XHTML 2.0 comes out. With care, I want to just put XHTML 2.0 stuff in my xhtml:div elements and let the down-stream appliation work it out. XHTML 2 does have a different namespace. Future versions of XHTML may or may not have a DIV element. I agree that this might be out the scope of Atom, but it does create problems for interoparability. Also, what do you expect feed readers to support for XHTML versions, etc. -- Anne van Kesteren http://annevankesteren.nl/
Re: content @type
Eric Scheid wrote: is there any functional difference between... content type=xhtml.../content and content type=application/xhtml+xml.../content ??? We really should have changed this IMHO. -- Anne van Kesteren http://annevankesteren.nl/
Re: s/url/web/
Anne van Kesteren wrote: EDITORIAL: There are a couple of places where we use uri in the markup, specifically the atom:uri element (3.2.2) and the uri attribute of atom:generator (4.2.5). In both cases they're not actually URIs, they're IRIs, so the name is WRONG, except for nobody knows what an IRI is so renaming them iri would be confusing, and anyhow everyone thinks of URLs not *RIs, but naming them url would be wrong too, so why don't we actually change them to say what they're there for not what their syntax is and use web in both cases? -Tim Web Forms 2 uses |type=uri| as well. (It accepts IRIs.) Web Forms 2 now uses |type=url| to be more consistent with CSS2.1. I suggest Atom does the same. (Change atom:uri to atom:url.) -- Anne van Kesteren http://annevankesteren.nl/
Re: s/url/web/
Martin Duerst wrote: url: -0.2 (outdated) It may be outdated, but it is the one everyone is using and it is also used by CSS. -- Anne van Kesteren http://annevankesteren.nl/
Re: s/url/web/
Tim Bray wrote: EDITORIAL: There are a couple of places where we use uri in the markup, specifically the atom:uri element (3.2.2) and the uri attribute of atom:generator (4.2.5). In both cases they're not actually URIs, they're IRIs, so the name is WRONG, except for nobody knows what an IRI is so renaming them iri would be confusing, and anyhow everyone thinks of URLs not *RIs, but naming them url would be wrong too, so why don't we actually change them to say what they're there for not what their syntax is and use web in both cases? -Tim Web Forms 2 uses |type=uri| as well. (It accepts IRIs.) -- Anne van Kesteren http://annevankesteren.nl/
More thouhts on PaceXhtmlNamespaceDiv
There is only a single way in which a required DIV element in |type=XHTML| would be useful. It would only be useful if the XHTML namespace was defined directly on the DIV element, like: atom:entry div xmlns=http://www.w3.org/1999/xhtml; ... /div /atom:entry The DIV element would obviously not be considered part of the content and all the elements inside the DIV element should inherit the XHTML namespace and should not have a namespace prefix. Than it would be possible to easy copy and paste and easily generate it from string-generators, like MovableType and WordPress. However, this would seriously limit |type=XHTML| and would require the Atom specification to define the DTD for the allowed XHTML elements. Since you can use MathML and SVG in a valid way inside the DIV element as well, with the proper DTD. For some people that is quite normal[1]. IMHO it would be better if your system can not guarentee to generate well-formed XHTML it would use |type=HTML|. That is also interoperable and can be easily copy and pasted. I think we should recommend that to publishers instead of limiting |type=XHTML|. However, if we do want to limit |type=XHTML| in this way we should do in a way that makes it useful. By defining the DTD and the exact way the namespace declarations should happen. [1]http://golem.ph.utexas.edu/~distler/blog/ -- Anne van Kesteren http://annevankesteren.nl/
Re: On PaceXhtmlNamespaceDiv
Bill de hra wrote: As long as it's XML and otherwise conformant, I think it's fine. Do you and Julian and Anne and Henri approve? I don't see how I would want to complain about how you generate your stuff, as long as the result is following the specs. The point I'm seeing here is that creating markup using string concats is inherently fragile. No surpise there. Wrt namespaces, fragility is eliminated when you stop using defaults (but there are other considerations which keep string concat fragile). Use of div covers off the XHTML case. IMHO you are better of using HTML in such cases. Since you can not guarentee that your input and therefore your output will always be well-formed XML. And, now I look at it, Robert is using HTML (the text/html MIME type implies that) so I do not see the problem. -- Anne van Kesteren http://annevankesteren.nl/
On PaceXhtmlNamespaceDiv (was: Re: Consensus call on last round of Paces)
Tim Bray wrote: PaceXhtmlNamespaceDiv This is tough. There are some people who are really against this and who aren't moving. On the other hand, there are way more who are in favor. Reviewing the discussion, the contras are saying that this is sloppy and unnecessary and if it solves a problem, that problem really shouldn't be there, but they don't seem to be saying it's actively harmful. But the people in favor are arguing that this will reduce errors and improve interop. Also, the Pace was changed in midstream. Also, Paul thinks we will get feedback on this from out there in the IETF. DISPOSITION: Borderline, but accepted. I'm still not sure how it would improve interop, especially since the place the namespace can be defined is optional. I do not think those Planet aggregators would handle the following correct for example: atom:entry xmlns:atom=... xmlns:b=http://www.w3.org/1999/xhtml; atom:content type=XHTML b:div Foo b:br / Et cetera. ... Also, this restriction can be avoided by using |type=application/xml| or |type=application/xhtml+xml| I assume? (Although that is probably not valid for the TITLE or SUMMARY element (it should be).) -- Anne van Kesteren http://annevankesteren.nl/
Difference between |rel=related| and the link it is about
For link weblogs (I run one) it would be very useful to be able to distinquise between the link you point to and the link it is about. Currently aggregators (like Hotlinks) take the first |rel=related| link and consider that to be the most important one. My weblog system does the same. Example: http://annevankesteren.nl/archives/href/2005/02#link-1306 The post is really about the ten new working drafts. That I read something slightly related is not really the subject of the post although it might be interesting to the reader. I proposed this ages ago and it would probably need another pace now (although I read those are not accepted anymore): |rel=about| Points to the resource the entry is about. That would be enough. Zero or more allowed. If this is not addressed I guess aggregators and publishing systems keep such hacks which would not be really nice. -- Anne van Kesteren http://annevankesteren.nl/
Re: PaceXhtmlNamespaceDiv
Sam Ruby wrote: New abstract: Given that common practice is to include this element, making it mandatory makes things clearer to both people who are producing consuming tools based on the spec, and people who are producing new feeds based on copy and paste. New spec text: The xhtml:div element itself MUST NOT be considered part of the content. I find it a bit problematic to use common practice in Atom feeds as justification for spec changes. Let's make the spec as clear and simple as possible. If this is in conflict with common usage in experimental Atom feeds, so be it. That is consistent with your prior statement that you don't believe that implementation issues should affect the format: http://www.imc.org/atom-syntax/mail-archive/msg12699.html Yes, I want a spec that is simple. I also want a spec that average people can implement simply and correctly. We have seen on this very mailing list people who have an above average understanding of XML trip over this particular area numerous times. I am not content to create a format for which the answers to such common user errors is so be it. However, what is the problem with people using a DIV element inside SUMMARY and the CONTENT element if they wish to do so? By the way, I have read the thing you wrote about things like planet copy the contents and put it in their own DIV element but if that is how they are going to treat Atom, Atom will not be solving anything and will just be another RSS I guess. Authors who do copy and paste and others should always validate their feed. I guess the feed validator could flag elements that are in the Atom namespace and should not be there according to the latest updates of the Atom namespace. Eventually, I guess it is about getting the major weblog systems and companies to get their implementation right. The Atom WG and other people should also provide tutorials on how to create Atom feeds and how to make sure everything works as it should. -- Anne van Kesteren http://annevankesteren.nl/
Re: PaceXhtmlNamespaceDiv
Henri Sivonen wrote: -1 on PaceXhtmlNamespaceDiv -1 from me as well. It is hack which might be useful for publishing systems (and perhaps aggregators) who do not use the right tools to generate a valid Atom file anyway. -- Anne van Kesteren http://annevankesteren.nl/
Re: PaceXhtmlNamespaceDiv
James M Snell wrote: Ok, now that I'm thinking about this more, I'm changing my initial +0 to +1. This just makes sense. There does need to be a container for the XHTML and div is a solid, logical choice. I don't think it should matter where the xmlns is declared... any ancestor element will do. I'm still -1. But I was wondering, why only ancestor elements? Wouldn't the most logical thing for string based generators be to apply it on the DIV element? -- Anne van Kesteren http://annevankesteren.nl/
Re: PaceXhtmlNamespaceDiv
James M Snell wrote: Nah, I don't buy it. XHTML is just a special case of an XML content and if we were embedding some XML data (say an atom:feed) it wouldn't make any sense (under the assumption that the content / element is top level container) for us to do: content type=application/atom+xml head ... /head entry ... /entry /content I do not follow this example. In my opinion, the XML contained in the content or text element should be capable of standing alone outside of the content element as a well-formed document and XHTML is just a special case of XML content. So you want a DIV as wrapper element for TITLE and similar elements as well? -- Anne van Kesteren http://annevankesteren.nl/
Re: PaceXhtmlNamespaceDiv
Sam Ruby wrote: Ok, now that I'm thinking about this more, I'm changing my initial +0 to +1. This just makes sense. There does need to be a container for the XHTML and div is a solid, logical choice. I don't think it should matter where the xmlns is declared... any ancestor element will do. I'm still -1. But I was wondering, why only ancestor elements? Wouldn't the most logical thing for string based generators be to apply it on the DIV element? I'm confused. If you are opposed to this pace, then what div element? That was a question in reply to what James wrote. It appeared to be an error. It may also be helpful to look at a specific feed, for example this one: http://www.imc.org/atom-syntax/mail-archive/msg12902.html Experiment with alternate serializations if you like. The important question is whether the div element is part of the format or part of the content? Should aggregators copy it? When an Atom entry is POSTed to a blog, is the div part of the content? If the page is adopted, which I hope not, it MUST NOT be part of the content. If the page is not adopted it MUST be part of the content. -- Anne van Kesteren http://annevankesteren.nl/
Re: Issues with draft-ietf-atompub-format-04
Robert Sayre wrote: I made that mistake because the draft in front of me is organized quite differently than the one in front of you. It was unclear to me as well. -- Anne van Kesteren http://annevankesteren.nl/
Re: Comments on format-05
* 4.15 The atom:content Element -- I strongly believe that more than one atom:content should be allowed; there are use cases when there are multiple representations of the item, and it is useful and necessary to communicate this in the feed. I suggest that multiple atom:content elements be allowed, as long as they have different type attributes. +1, but not just type attributes, also xml:lang variations please. -1. An Atom entry is *one* representation and you can link to alternates. I'm deeply unhappy that this was raised again. We went over and over on the matter, and no one ever used them anyway. +1. I think it is important to include multiple translation in a single feed. The option of giving people alternatives makes sense too. Especially since there is no option for a fallback mechanism. Furthermore, as pointed out before, that restraint does not make much sense since you can easily emulate the whole fallback thing with XHTML which is allowed as content model. -- Anne van Kesteren http://annevankesteren.nl/
Re: Issues with draft-ietf-atompub-format-04
Robert Sayre wrote: So I can not include MathML in the TITLE of my weblog? I do not see why this restriction is necessary. Nope. Can any aggregator display it? I wonder if Shrook users are filling Graham's inbox with requests for MathML in their titles. Addressed in a separate thread. In Europe there are lots of different languages. It does not make sense to provide a feed based on language negotiation since feed aggregators do not support that. There are lots of different languages in America, too! I thought the only official language was en-US? Either Atom should provide support for multiple languages or we should address something like feed language negotiation in the specification. If what you say is true, then aggregators don't support multiple alternatives at all right now. Content Negotiation is covered by RFC2616. I believe most support content negotiation. However, I do not believe they send out an Accept-Language header. I think version should be dropped. We can always add it later. True. But that does not help current aggregators. At least, they will not reject new feeds. They will just found out they can not parse them at some point. The namespace will change. Only for the elements that are changed? -- Anne van Kesteren http://annevankesteren.nl/
Re: PaceFeedRecursive is filled in
Robert Sayre wrote: Hmm. How do I do a linkblog with this restriction? I believe a linkblog should always have atom:content which provides some information on the reason why you posted the link or a comment on the link or something similar. -- Anne van Kesteren http://annevankesteren.nl/
Re: URI canonicalization
Robert Sayre wrote: How about this: The only comparison method Atom Processors MUST support is character-by-character comparison [RFC3986]. Atom Processors MAY perform additional scheme-specific comparisions. If you do this: http://Example.org/thing http://example.org/thing You cannot count on a positive or negative, and you are sloppy. That would mean that the implementation could differ between Atom processors, right? And that in your example one would return true and the other false when the URIs are compared? Tim: http://www.intertwingly.net/blog/2004/07/31/URI-Equivalence -- Anne van Kesteren http://annevankesteren.nl/
Re: PaceIRI status
Julian Reschke wrote: The big difference here is that XMLNS uses IRIs/URIs as identifiers and only for that. However, what is an XSLT that transforms Atom content to HTML supposed to do when it encounters a IRI which isn't a legal URI? For instance, it can't put it into an HTML href attribute without producing invalid HTML. I guess that is a HTML errata issue rather then an Atom issue. Atom can not make sure it is compatible with every specification out there. Perhaps we could add an informative about it although I doubt if it would be useful. Furthermore, browsers do not really support IRIs either so authors are not likely to use them in HTML context anyway. -- Anne van Kesteren http://annevankesteren.nl/
