Re: PaceIRI status

support IRIs either so authors are not likely to use them in HTML context anyway. -- 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

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

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

-- 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

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

you want a DIV as wrapper element for TITLE and similar elements as well? -- Anne van Kesteren http://annevankesteren.nl/

Re: PaceXhtmlNamespaceDiv

? 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: PaceXhtmlNamespaceDiv

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/

Difference between |rel=related| and the link it is about

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

On PaceXhtmlNamespaceDiv (was: Re: Consensus call on last round of Paces)

be).) -- Anne van Kesteren http://annevankesteren.nl/

Re: On PaceXhtmlNamespaceDiv

. 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/

More thouhts on PaceXhtmlNamespaceDiv

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: s/url/web/

. (It accepts IRIs.) -- 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

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: 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: HTML/XHTML type issues, was: FW: XML Directorate Reviewer Comments

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: 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

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: xml:base and html rendering

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: suggestion: mention about xml:id

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

). 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/

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: 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/

Re: Atom Implementation Guide: seeking co-editor

equal to the implementation guide. -- Anne van Kesteren http://annevankesteren.nl/

Re: Which is the preferred feed?

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

Re: Which is the preferred feed?

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: Autodiscovery paces

. 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

=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: atom:modified : Reducing the cruft

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

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

Re: 4.2.7.1 Comparing atom:id

in a future draft? -- Anne van Kesteren http://annevankesteren.nl/

Re: 4.2.7.1 Comparing atom:id

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: some small comments on 08

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

Re: Author and contributor

need for it. Again, +1 to Antones suggestion. +1. -- Anne van Kesteren http://annevankesteren.nl/

Re: The Atomic age

the world. -Tim Yay! (Except for the namespace that is. Ouch!) -- Anne van Kesteren http://annevankesteren.nl/

[feedvalidator] amp;apos; is not HTML

-- Anne van Kesteren http://annevankesteren.nl/

Re: ACE - Atom Common Extensions Namespace

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

not do this. -- Anne van Kesteren http://annevankesteren.nl/

Re: finishing autodiscovery, like now

is that relevant? -- 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: Browser behaviour

) 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: 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: atom:name ... text or html?

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: Does xml:base apply to type=html content?

weeklies should do the same... -- Anne van Kesteren http://annevankesteren.nl/

Re: Does xml:base apply to type=html content?

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?

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: 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

Re: Atom and bidi

instance of xml:lang. Your point being? -- 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 namespace really not ending with / or # ?

/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

Re: Atom Entry docs

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

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

Re: Text-type contents and White Space

. -- Anne van Kesteren http://annevankesteren.nl/ http://www.opera.com/

Re: base within HTML content

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

Re: base within HTML content

. But nothing like that is defined... -- Anne van Kesteren http://annevankesteren.nl/ http://www.opera.com/

Re: base within HTML content

you to where HTML is now (at best). -- Anne van Kesteren http://annevankesteren.nl/ http://www.opera.com/

Re: base within HTML content

/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

Re: Autodiscovery Draft

-- Anne van Kesteren http://annevankesteren.nl/ http://www.opera.com/