Re: Representing bookmarks

[A. Pagaltzis]

* Erwan Loisant <[EMAIL PROTECTED]> [2007-03-09 22:40]:
> I'm not sure whether they're doing it "the right way" or not,

Oh yeah, they do. The bookmark is a `related` link, the
`alternate` link points at a page for the link on Blogmarks
itself, and the description, if any, is in `content`. Just as
it should be. They don’t even throw crappy aggregators a bone
by duplicated the bookmark as a link in the content, which is
just as well.

Regards,
-- 
Aristotle Pagaltzis // 

Re: Representing bookmarks

[A. Pagaltzis]

* Brendan Taylor <[EMAIL PROTECTED]> [2007-03-09 21:50]:
> He has an XSLT which transforms del.icio.us into Atom [1]; (the
> important bit of) the entries it produces look like this:
> 
>   
> The Atom Syndication Format
> An alternative to RSS2.
> http://www.ietf.org/rfc/rfc4287"/>
> 
>   
> 
> (I was thinking along the same lines, but using content/@src
> instead of link/@href.)
> 
> But he (and now I) is not entirely happy with this solution. 

For the purpose of discussion, here’s how I’d do that now:


The Atom Syndication Format
http://del.icio.us/url/longhashvaluehere"/>
http://www.ietf.org/rfc/rfc4287"/>

http://www.ietf.org/rfc/rfc4287"/>The Atom Syndication 
Format:
An alternative to RSS2.




It bugs me to repeat the link in the content, but the all-around
absence of support for `related` links requires this sort of hack
to make the feed useful with today’s aggregators. Even then, such
a feed would not be useful as a Live Bookmark in Firefox.

Regards,
-- 
Aristotle Pagaltzis // 

Re: Current and permalink link rel values

[A. Pagaltzis]

* Elliotte Harold <[EMAIL PROTECTED]> [2007-02-23 15:15]:
> I'd like to add multiple links to my feed for both the current version 
> of the story and the permalink. E.g.
> 
>  
> Matt Mullenweg has released Wordpress 2.1.1 and 2.0.9.
>   
> 
>   http://www.w3.org/1999/xhtml"; 
> id="February_22_2007_30633" class="2007-02-22T09:31:33Z">
> 
> Matt Mullenweg has released  href="http://wordpress.org/development/2007/02/new-releases/";>Wordpress 
> 2.1.1 and 2.0.9.
> 
> 
> 
> 
> http://www.cafeconleche.org/#February_22_2007_30633"/>
>  href="http://www.cafeconleche.org/oldnews/news2007February22.html#February_22_2007_30633"/>
> http://www.cafeconleche.org/#February_22_2007_30633
> 2007-02-22T09:31:33Z
>   
> 
> In particular is "rel='permalink'" a reasonable way to do this?

It should be `rel="alternate"`.

> Might it make sense to register current and permalink values
> for the rel attribute in the IANA Registry of Link Relations?

What’s the purpose of the `current` link? Is there ever a case
where it would be bad to send the reader to the permanent
location of the item?

Regards,
-- 
Aristotle Pagaltzis // 

Re: self and alternate links for entries

[A. Pagaltzis]

* Bill de hOra <[EMAIL PROTECTED]> [2007-01-30 14:20]:
> I couldn't find enough information in the RFC about which way
> to go. Which would you choose, and why?

The “self” relation means “this same Atom Document you’re just
looking at.” The “alternate” relation means “another
representation of the same resource that this Atom Document
represents.”

Which option is correct should be pretty clear from that.

Regards,
-- 
Aristotle Pagaltzis // 

Re: atom dates

[A. Pagaltzis]

* fschmidt <[EMAIL PROTECTED]> [2007-01-10 05:40]:
> I implemented an atom feed as specified in RFC 2487 using the
> "updated" date element. But the dates in my feed doesn't work
> in atom readers like Google Reader.

The second sentence seems to be contradicting the first.

Did you validate your feed?

Regards,
-- 
Aristotle Pagaltzis // 

Re: Additional 'namespace' attribute on content element?

[A. Pagaltzis]

* James Aylett <[EMAIL PROTECTED]> [2007-01-04 18:55]:
> I don't see a big difference between dispatch on namespace of
> child of content (which is, I believe, legal in Atom 1.0) and
> dispatch on namespace attribute on content (which is what I
> think you're proposing).

Except when there is nothing you can dispatch on because the
vocabulary in question is not in a namespace.

Regards,
-- 
Aristotle Pagaltzis // 

Re: within HTML content

[A. Pagaltzis]

* 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
> "" to what travels in the
> feed and append "" 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 ``.

Regards,
-- 
Aristotle Pagaltzis // 

Re: within HTML content

[A. Pagaltzis]

* Geoffrey Sneddon <[EMAIL PROTECTED]> [2007-01-01 19:00]:
> On 1 Jan 2007, at 16:59, Asbjørn Ulsberg wrote:
> >the  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.
> 
> Web Applications 1.0 (keeping with the real world) defines that it  
> should be moved to HEAD within the DOM tree.

Thereby, of course, breaking the links in any other entries
rendered in the same page by a web-based aggregator, f.ex.

> Why, may I ask, MUST (under the RFC 2119 definition) HTML content be  
> a fragment ("HTML markup within SHOULD be such that it could validly  
> appear directly within an HTML  element, after unescaping." -  
> note the word SHOULD, not MUST, implying that you can have a full  
> HTML document within)?

Because many aggregators (most, very likely) do not render items
in isolation, but rather in some sort of collection, either
across feeds as a “river of news” or even just several within a
single feed. (Weblog engines do that when showing the front page
of the weblog or archive for particular intervals.) They will
usually strip any header-level information from your entry, so
putting such elements in the content will usually fail to achieve
what you wanted – hence the SHOULD.

Regards,
-- 
Aristotle Pagaltzis // 

Re: Text-type contents and White Space

[A. Pagaltzis]

* Franklin Tse <[EMAIL PROTECTED]> [2006-12-30 11:05]:
> IE and Firefox both failed to display text/plain contents.
> Opera can but all white space was collasped

Yeah, I suspected that. Of course, none of the support xml:space
either, but the semantics of using text/plain are already obvious
without having to amend the spec and supporting it should take
minimal effort, so I would file bugs.

Almost no consumer at this point is prepared to process anything
but HTML and inline text since almost everyone just treats Atom
as a dialect of RSS 2.0. If you need the interoperability right
now, you will have to keep doing what you’re already doing with
`type="html"` containing `` tags.

Regards,
-- 
Aristotle Pagaltzis // 

Re: Text-type contents and White Space

[A. Pagaltzis]

* Franklin Tse <[EMAIL PROTECTED]> [2006-12-30 09:10]:
> In Section 3.1.1.1. of RFC 4287,
> 
>If the value is "text", the content of the Text construct
>MUST NOT contain child elements. Such text is intended to be
>presented to humans in a readable fashion. Thus, Atom
>Processors MAY collapse white space (including line breaks)
>and display the text using typographic techniques such as
>justification and proportional fonts.
> 
> However, white space in some text contents cannot be collapsed.
> Otherwise, the contents will be broken.

Use `type="text/plain"`. The `text` type is intended for limited
amounts of inline content that can be rendered in menus, lists
and the like, not for substantive amounts of content.

Regards,
-- 
Aristotle Pagaltzis // 

Re: AD Evaluation of draft-ietf-atompub-protocol-11

[A. Pagaltzis]

* Lisa Dusseault <[EMAIL PROTECTED]> [2006-12-16 02:15]:
> Since clients post Atom entries and other clients retrieve
> them, it seemed reasonable to want to extend Atom
> client-to-client. If I used "AtomFu" client that was able to
> annotate my entries automatically with what music I was
> listening to (track name, album and artist in XML elements)
> while I wrote a blog posting, I thought AtomFu should just
> store that as XML markup in the entry.

That is, IMO, a misconception about Atom – one that is frequently
seen. We just had a similar discussion tonight in #atom on the
Freenode IRC network. The track name, album and artist are data;
they should be part of the payload of an entry, not part of its
envelope. In practice, that means you use either microformats or
a more structured format than HTML. Extending the Atom envelope
is a strategy of last resort.

Regards,
-- 
Aristotle Pagaltzis // 

Re: Atom Entry docs

[A. Pagaltzis]

* Bob Wyman <[EMAIL PROTECTED]> [2006-12-14 05:45]:
> 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

Regards,
-- 
Aristotle Pagaltzis // 

Re: PaceEntryMediatype

['A. Pagaltzis']

* Franklin Tse <[EMAIL PROTECTED]> [2006-12-07 10:00]:
> If browsers do not support text/plain as a stylesheet, they
> should just simply ignore  type="text/plain" href="/style.css" />.

Exactly.

Regards,
-- 
Aristotle Pagaltzis // 

Re: PaceEntryMediatype

[A. Pagaltzis]

* Jan Algermissen <[EMAIL PROTECTED]> [2006-12-07 08:25]:
> As an analogy: HTML browsers look for stylesheets where it says
> 
>
> 
> and not
> 
>
> 
> Eh?

What do browsers do with this?



And what with this?



Is their behaviour right? Wrong? Why?

Regards,
-- 
Aristotle Pagaltzis // 

Re: PaceEntryMediatype

[A. Pagaltzis]

* Jan Algermissen <[EMAIL PROTECTED]> [2006-12-06 20:55]:
> But that is an issue of linking semantics, not link target
> media types. 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.
> 
> IMHO, there is something going wrong somewhere - and it ain't
> the media type.

It seems pointless for atom:link to have a type attribute at all
then. You should be able to decide anything you need to decide by
GETting the resource (and sometimes parsing it). Why did we add
such a useless feature to the spec?

Regards,
-- 
Aristotle Pagaltzis // 

Re: PaceEntryMediatype

[A. Pagaltzis]

* Mark Baker <[EMAIL PROTECTED]> [2006-12-04 21:35]:
> If it looks like an alias, and acts like an alias ... 8-)

It doesn’t.

For resource creation this specification only defines cases
where the POST body has an Atom Entry entity declared as an
Atom media type ("application/atom+xml"), or a non-Atom
entity declared as a non-Atom media type. It does not specify
any request semantics or server behavior in the case where
the POSTed media-type is "application/atom+xml" but the body
is something other than an Atom Entry. In particular, what
happens on POSTing an Atom Feed Document to a Collection
using the "application/atom+xml" media type is undefined.

Regards,
-- 
Aristotle Pagaltzis // 

Re: PaceEntryMediatype

[A. Pagaltzis]

* James M Snell <[EMAIL PROTECTED]> [2006-11-29 17:40]:
> http://www.intertwingly.net/wiki/pie/PaceEntryMediatype

+1


* Thomas Broyer <[EMAIL PROTECTED]> [2006-11-29 20:35]:
> 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

-0

> 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

+1

I like this very much; it would put some order in the
proliferation of Atom-related MIME types.

> As for Tim's concerns, I'd also prefer having it done outside
> the APP.

+0

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

+1

Unification is good.

Regards,
-- 
Aristotle Pagaltzis // 

Re: PaceEntryMediatype

[A. Pagaltzis]

* Mark Baker <[EMAIL PROTECTED]> [2006-11-29 20:10]:
> An entry document is, AFAICT, little more than shorthand for
> a feed with one entry, minus the feed-specific metadata. It's
> processing is a subset of feed processing. If the processing or
> content model of entry is extended, it applies to both feed
> documents and entry documents.

I disagree. There’s not much of a point in subscribing to an
entry document, and APP servers will not accept POSTing feeds in
place of entries.

[Note: subscribing to an entry document is actually somewhat
useful in one sense and might become customary in the future,
eg. to track changes to a document. However, that’s still an
entirely different use case from subscribing to feed.]

Regards,
-- 
Aristotle Pagaltzis // 

Re: Autodiscovery IPR and Process Concerns

[A. Pagaltzis]

* Robert Sayre <[EMAIL PROTECTED]> [2006-11-30 08:10]:
> On 11/30/06, James M Snell <[EMAIL PROTECTED]> wrote:
> >   If y'all think
> 
> Ah, this is what's called "innappropriately folksy". It's
> a common rhetorical device used when the speaker wants to
> appear that they're on the side of "the common man" or
> equivalent.

What rhetorical device is it to point out the rhetorical devices
used by other participants in a discussion?

> The president of the United States makes frequent use of this
> device.

What rhetorical device is it to use inappropriate and entirely
irrelevant political analogies in the hopes of derailing
a discussion?

Regards,
-- 
Aristotle Pagaltzis // 

Re: WHAT-WG, feed and alternate (was: Re: PaceAutoDiscoveryDraftIsPointless)

[A. Pagaltzis]

* James M Snell <[EMAIL PROTECTED]> [2006-11-29 00:20]:
>   3. We define a new media type for Atom Entry Documents,
>  e.g. application/atomentry+xml

+1


* Robert Sayre <[EMAIL PROTECTED]> [2006-11-29 00:40]:
> We should tack it onto the APP draft, since that will solve
> issues with the accept element there. And praise to mnot, who
> suggested we do this in RFC4287 but was overruled by the WG
> (including myself).

+1


(Wow, I +1ed both James and Robert in the same mail. :-) )

Regards,
-- 
Aristotle Pagaltzis // 

Re: Author element best practice

[A. Pagaltzis]

* Asbjørn Ulsberg <[EMAIL PROTECTED]> [2006-11-27 20:55]:
> 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?

I get your concern and to some extent I share it, but I’m unsure
about how it could be addressed. If we assume that servers can
implement wildly different feature sets and special cases, then
there is a huge number of conditions which the server would need
to be able to somehow signal. I don’t know how we can allow for
that. A special error document XML vocabulary for those cases
where the HTTP status is not granular enough would be an option.
Some document making suggestions about what error status codes to
use in which circumstances could also help unify expectations.
But the scope of any such endeavour will be huge…

Regards,
-- 
Aristotle Pagaltzis // 

Re: Author element best practice

[A. Pagaltzis]

* Sylvain Hellegouarch <[EMAIL PROTECTED]> [2006-11-23 00:00]:
> 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 ?

+0 to MAY. I'm not sure it needs to be stated explicitly. It
seems obviously implied by the APP axiom that the server is
ultimately in control.

But -1 to SHOULD. If the server thinks it has enough data to
flesh out an incomplete entry so that it is valid, it should be
free to do as it pleases.

Regards,
-- 
Aristotle Pagaltzis // 

Re: Author element best practice

[A. Pagaltzis]

* Sylvain Hellegouarch <[EMAIL PROTECTED]> [2006-11-22 12:25]:
> do you think it'd be better to put an empty atom:name or to put
> a dummy value such as 'anonymous' or 'n/a'?

Ugh. Dummy values are nasty, perverse and evil. Someone *will*
eventually suffer miserably if you pollute your data like that.

Don’t you have any identifying information about who is POSTing
the entry? That’s where I’d look to.

Regards,
-- 
Aristotle Pagaltzis // 

Re: PaceResurrectAutodiscovery

[A. Pagaltzis]

* Eric Scheid <[EMAIL PROTECTED]> [2006-11-22 01:20]:
> I suggest a relationship value of "feed", to use when pointing
> to a feed. Note that multiple values for @rel are still
> possible with html's link (e.g. @rel="feed alternate").

-1 to any changes that would be incompatible to existing dead
draft, at any time.

-1 also to changing the draft at all prior to resurrection. We
can see whether we want any new language in there once we have it
back in the process.

+0 to including *additional* provisions in the draft before
submitting it for approval, because I do agree it’s incomplete.

I’d like to see the current status quo documented. There are
millions of pages out there already implementing autodiscovery
according to the dead draft, and lots of code to process them,
but there is no official documentation for any of this. There
should be a spec for it.

Regards,
-- 
Aristotle Pagaltzis // 

Re: The "src" attribute of atom:content

[A. Pagaltzis]

* Tse Shing Chi (Franklin/Whale) <[EMAIL PROTECTED]> [2006-11-19 16:05]:
> Unfortunately, numbers of feed aggregators will not follow the
> src attribute probably due to security reasons.

atom:content/@src is indeed not well supported. Many aggregators
aren’t even aware of the attribute and don’t do even as much as
showing a link to the external content. This is broken; please
file a bug against the aggregator in question.

> However, it is actually an abuse of atom:summary because the
> "atom:summary" element is a Text construct that conveys a short
> summary, abstract, or excerpt of an entry.
 
Agreed.

> More unfortunately, feed aggregators will not consider this
> entry is linking to http://www.example.org/ even though the
> content is external.

This is correct and by design (though implementation correctness
here is probably often by accident; see above).

> The followings are my thoughts.
> 
> 1. When the "src" attribute of atom:content is present, it
> includes the meaning of having an alternate link to the same
> URI inside "src".
> 
> 2. atom:content SHOULD NOT be empty. I think that atom:content
> is something like xhtml:object. Alternate contents should be
> put inside the element.

We could discuss whether these ideas would have been worthwhile.
However, this is moot, as the spec is done and cannot be changed.
Since these suggestions are incompatible with RFC 4287, they
cannot be recommended as best practices either. Sorry. :-(

Regards,
-- 
Aristotle Pagaltzis // 

Re: Forward Compatibility

[A. Pagaltzis]

* Elliotte Harold <[EMAIL PROTECTED]> [2006-11-18 21:00]:
> Mark Nottingham wrote:
> >Atom has a namespace; that can be use to introduce new
> >versions of the format. 
> 
> No, no, and no. We've been down this road before in other
> specs, and the community wisdom is that you do not rev the
> namespace just to introduce a new version. Doing so breaks
> a huge amount of the existing processing chain for an
> application.
> 
> It is, of course, possible to introduce new elements in other
> namespaces; and the Atom spec does a much better than average
> job of preparing for this. Indeed there are already many
> interesting extensions.
> 
> However, even if fundamental flaws were found in Atom 1.0 that
> required revisions and an Atom 1.1 or 2.0, the namespace should
> and almost certainly woulds remain the same.

Yes and no.

If future changes can be made in a backward-compatible
fashion, they will go into a spec that recycles the same
namespace. Existing implementations can just ignore the
differences.

If they cannot, they will go into a spec which revs the
namespace, because trying to process documents conforming
to the new spec with existing implementations can’t work.

In neither case is there a need to identify the version
explicitly.

This is why Atom does not have a version attribute.

All that said, the goal during development was always that
Atom would ship when it was done and be stable thereafter.
It is now set in stone for the forseeable future. No further
development of the core format is expected. (Instead, the
spec includes a number of extension points that can be used
to repurpose the format to new use cases.)

This is another reason why Atom does not have a version
attribute.

Regards,
-- 
Aristotle Pagaltzis // 

Re: categories and tagging

[A. Pagaltzis]

* Henry Story <[EMAIL PROTECTED]> [2006-11-02 16:55]:
> The question is: how does this help any of us? It may look like
> it is a "term", but what is a client meant to do with all this
> information?

Simple: when the scheme and term of two different entries are
identical, then you have confidence that they refer to the same
concept. When the scheme URI is absent, the term is ambiguous.

That’s what scheme and term mean, and that’s all that they mean.

If you want to use a dereferencable protocol scheme for your
category’s scheme URI, and want to run a service providing
resources at the given URI, that’s fine, and more power to you.
But nothing like that is mandated, much less is any approach for
deriving a dereferencable URI for a single term.

Regards,
-- 
Aristotle Pagaltzis // 

Re: html content, xml:base and xml:lang

[A. Pagaltzis]

> Does xml:base and xml:lang apply to html encoded content?

Yes, definitely.
-- 
GMX DSL-Flatrate 0,- Euro* - Überall, wo DSL verfügbar ist!
NEU: Jetzt bis zu 16.000 kBit/s! http://www.gmx.net/de/go/dsl

Re: Adding POST capability to atom:link

[A. Pagaltzis]

* Gopalan Sri <[EMAIL PROTECTED]> [2006-10-26 18:50]:
> The information I want to pass back to the server is complex in
> nature and makes sense to capture in XML. My question is
> whether or not there are any thoughts or plans to extend the
> atom:link contruct to support something like this:

My answer is that the element is called `link` and you’re asking
for something other than a link.

I certainly hope that clients will never ever be expected to
issue anything other than GET in order to dereference a link.

If you describe the nature of the task you want to perform,
someone might be able to suggest a better mechanism for
expressing it.

Regards,
-- 
Aristotle Pagaltzis // 

Re: Question on undefinedAttribute/Content

[A. Pagaltzis]

* Jan Algermissen <[EMAIL PROTECTED]> [2006-10-18 10:45]:
> RFC4287 distinguishes between 'undefined' and 'extension'
> constructs. I am understanding the distinction to imply that
> conformant software should provide for handling extension
> elements, but can and should ignore any occurrences of
> undefinedAttribute or undefinedContent.
> 
> Is that understanding correct?

Yes. To be precise:

Extension constructs are any markup which the software knows to
interpret.

Undefined markup is anything it doesn’t know to interpret. In
particular, this includes any future additions to Atom itself.

Regards,
-- 
Aristotle Pagaltzis // 

Re: Atom Export

[A. Pagaltzis]

* Alastair Rankine <[EMAIL PROTECTED]> [2006-10-17 15:35]:
> I thought it might be simpler for the *exporter* to choose
> a content  syntax - perhaps with the help of the user - which
> is deemed to be  the most interoperable, and yet closest to the
> original.

That is a good counter.

However, you still need to address the restriction of text
constructs, namely that in Atom, they can be only of type `text`
(with no semantics implied for whitespace), `html` or `xhtml`.
Without further provisions you can only export the cooked content
of elements other than atom:content.

Regards,
-- 
Aristotle Pagaltzis // 

Re: Atom Export

[A. Pagaltzis]

* Alastair Rankine <[EMAIL PROTECTED]> [2006-10-17 14:05]:
> So the list is now:
> 
> 1. Complete list of authors defined. For each author:
>   a. Name
>   b. URI
>   c. email
> 2. Complete list of categories defined:
>   a. Name
>   b. URI
> 3. All articles. For each article:
>   a. Source text
>   b. All the relevant metadata from the Atom spec, namely:
>   author, ID, published, rights, title, updated, summary, 
>   categories
>   c. Some other metadata:
>   draft status, syntax of source
> 4. All comments and trackbacks. For each comment or trackback:
>   a. Source text
>   b. Atom spec metadata:
>   author, ID, title, published, summary, avatar?
>   c. Additional metadata:
>   pointer to parent article or comment (ie "in-reply-to")
> 5. All "Owned" media. For each media object:
>   a. URI
>   b. MIME type
>   c. Binary data
> 
> Does this look about right? Obviously there would need to be
> a liberal sprinkling of extension points for proprietary
> information.

I think it is a good idea to also include the translated text of
each article, comment, etc. Eg. if they’re written in Markdown,
they should be accompanied by an HTML version, so that when
migrating to an engine which does not have Markdown support, such
articles and comments are not lost.

The trouble is with the content model. Suppose a weblog
supports distinct summaries and main articles, and it supports
Markdown. Firstly, text constructs do not support arbitrary MIME
type; only atom:content does. Secondly, there are then two
instances of the textual content of every supported field. If
titles may contain inline Markdown markup, how do you preserve
that?

I’m not sure what to do about this. The first thing that comes
to mind is that to accompany each atom:foo text construct with
a corresponding src:foo element, but I don’t know whether this is
a good idea. There are two options here: either the elements are
placed directly inside the atom:entry as extension elements, or
they are collectively placed inside the atom:content as instances
of an independent XML vocabulary. The latter seems favourable,
but again I don’t know whether any of this is really a good idea.

Regards,
-- 
Aristotle Pagaltzis // 

Re: Atom Export

[A. Pagaltzis]

* James M Snell <[EMAIL PROTECTED]> [2006-10-04 17:30]:
> I would add to this information about what plugins have been
> applied and what templates have been used. These, of course,
> are not going to be portable to different blog environments but
> the information would be necessary in order to faithfully
> recreate the entries later.

-1

These should be engine-specific extensions. The format should be
broad enough in scope that it can reasonably be used to transport
a weblog between engines, but not broader. What you’re looking
for is a full backup, but that’s a different use case than what
(I think) this spec aims for.

Regards,
-- 
Aristotle Pagaltzis // 

Re: Searching for Atom-enabled code

[A. Pagaltzis]

Hi John,

* John Panzer <[EMAIL PROTECTED]> [2006-10-05 23:25]:
> 
> Using Google codesearch:

interesting results, though the numbers are brittle. I tried to
go through the entire result set for Perl f.ex., and on page 2
the number went down from 100 to 50, and on page 3 down further
to 45, and stayed there.

Still, it’s neat. It’s also interesting to contrast the numbers
for the MIME type with those for the namespace.

> Java: 
> http://google.com/codesearch?hl=en&lr=&q=lang%3Ajava+application%2Fatom%5C%2Bxml&btnG=Search
>
> (50 results)

http://google.com/codesearch?hl=en&lr=&q=lang%3Ajava+http%3A%2F%2Fwww.w3.org%2F2005%2FAtom&btnG=Search
(50 results)

> C++: 
> http://google.com/codesearch?hl=en&lr=&q=lang%3Ac%2B%2B+application%2Fatom%5C%2Bxml&btnG=Search
> 
> (10 results)

http://google.com/codesearch?hl=en&lr=&q=lang%3Ac%2B%2B+http%3A%2F%2Fwww.w3.org%2F2005%2FAtom&btnG=Search
(3 results)

> Ruby: 
> http://google.com/codesearch?hl=en&lr=&q=lang%3Aruby+application%2Fatom%5C%2Bxml&btnG=Search
>   
> (50 results)

http://google.com/codesearch?hl=en&lr=&q=lang%3Aruby+http%3A%2F%2Fwww.w3.org%2F2005%2FAtom&btnG=Search
(50 results)

> Perl: 
> http://google.com/codesearch?hl=en&lr=&q=lang%3Aperl+application%2Fatom%5C%2Bxml&btnG=Search
>  
> (100 results)

http://google.com/codesearch?hl=en&lr=&q=lang%3Aperl+http%3A%2F%2Fwww.w3.org%2F2005%2FAtom&btnG=Search
(50 results)

> C#: 
> http://google.com/codesearch?hl=en&lr=&q=lang%3Ac%23+application%2Fatom%5C%2Bxml&btnG=Search
>
> (9 results)

http://google.com/codesearch?hl=en&lr=&q=lang%3Ac%23+http%3A%2F%2Fwww.w3.org%2F2005%2FAtom&btnG=Search
(8 results)

> Python:
> http://google.com/codesearch?hl=en&lr=&q=lang%3Apython+application%2Fatom%5C%2Bxml&btnG=Search
> (100 results)

http://google.com/codesearch?hl=en&lr=&q=lang%3Apython+http%3A%2F%2Fwww.w3.org%2F2005%2FAtom&btnG=Search
(50 results)

Regards,
-- 
Aristotle Pagaltzis // 

Re: Clarify foreign markup: [was Atom Syndication Format To Draft Standard?]

[A. Pagaltzis]

* Bill de hOra <[EMAIL PROTECTED]> [2006-10-04 03:55]:
> A. Pagaltzis wrote:
> >I think given the above background you'll agree that the
> >intent of the document is pretty coherent. 
> 
> I couldn't tell whether new Atom extensions are foreign markup,
> or something else to be dealt with under wrt being
> a "forward-compatible" friendly consumer. It's kind of
> circular.

That’s what I meant. The intent is well thought-out and sharply
defined (in the mathematical sense), but it’s specification in
the document is not very explicit. It could stand to be clarified
a bit so that people don’t have to ask on the list to have
someone from the old boys club educate them before they know how
to read the spec.

Since you’re fresh from newly reading that section, how would it
have had to read in order to convey its meaning clearly?


* Robert Sayre <[EMAIL PROTECTED]> [2006-10-04 04:20]:
> Bill, please show us a bug?

Bugs concerning forward compatibility are unlikely to surface
prior to Atom getting revised in some form. It’d be good if the
spec is clear enough that implementations have a chance to react
interoperably in the eventuality of such revisions.

It’s not some huge roadblocking issue, but neither is it without
merit. If it can be removed with an extra sentence in the spec
and a tweak to another and the opportunity is there, that seems
like a worthwhile small win to me. Polish shows in the details.

> I don't think defining terms until we've got a good subset of
> an English dictionary will make the format more interoperable.

Noone said anything about defining new terms.

Regards,
-- 
Aristotle Pagaltzis // <http://plasmasturm.org/>

Re: Clarify foreign markup: [was Atom Syndication Format To Draft Standard?]

[A. Pagaltzis]

* Bill de hOra <[EMAIL PROTECTED]> [2006-10-04 01:15]:
> Perhaps this is what's intended by those statements:
> 
> """
> Markup not defined in this document is called "foreign markup"
> """

No, I seem to remember pretty clearly from discussion that what
it means is thus:

Markup not known to the consumer is called "foreign markup"

That is, extension markup the consumer knows to interpret is not
foreign markup. In contradistinction, Atom markup that the
consumer does not know to interpret *is* foreign markup (eg.
attributes from a hypothetical future version of Atom).

The document then sets forth how foreign markup should be
interpreted, ie. basically what the consumer should do on finding
things in a feed that it doesn't understand.

> I don't think the document can forward to proposed without
> clarification. Also, "forward-compatible" is mentioned, but not
> defined - it's not possible to make a safe assumption on what
> it means, since it's relative to whatever "foreign markup" is.
> I assume "unrecognized" and "unknown" are synonymous.

I think given the above background you'll agree that the intent
of the document is pretty coherent. A clarification that makes
this background explicit would undoubtedly be helpful, though.

Regards,
-- 
Aristotle Pagaltzis // 

Re: Atom Export

[A. Pagaltzis]

* Elliotte Harold <[EMAIL PROTECTED]> [2006-10-02 16:40]:
> It would essentially rule out using DOM to process this stuff,
> for example.

OK, sold. I hadn’t thought of that.

Regards,
-- 
Aristotle Pagaltzis // 

Re: Atom Export

[A. Pagaltzis]

* Alastair Rankine <[EMAIL PROTECTED]> [2006-10-03 12:40]:
> Instead, how about this: a zipfile with a single "index.xml"
> file containing the Atom export document (as currently
> proposed), with all other resources added to the zipfile
> according to their relative URLs from the site being exported.

I’d rather the normative URIs for the media resources be given by
way of an alternate link in entries associated with each of the
resources. You’ll want such entries anyway in order to store any
associated textual data (eg. the description of an image) and
preserve other metadata such as who uploaded a file. Within the
zip, the file would be identified by using the atom:content/@src
attribute. The zip structure could be completely free-form with
the exception of the name and placement of the master feed.

Regards,
-- 
Aristotle Pagaltzis // 

Re: Atom Export

[A. Pagaltzis]

* James M Snell <[EMAIL PROTECTED]> [2006-09-29 14:17]:
> I've been stewing lately over the possibility of doing
> something similar to this but wrapping the atom documents and
> associated resources into a zip. A single master atom feed
> would provide an index of the archive, with individual entries
> either contained in that index feed or as separate entry
> documents

Why the zip? Atom is an envelope format that can transport binary
content. So is tar. Just gzip the Atom feed; instead of .tar.gz
(which usually compresses better than zips) you get .atom.gz.

Hmm. Maybe we should call these Atomballs?

Buckminsterfullerenes? :-)

Regards,
-- 
Aristotle Pagaltzis // 

Re: atom license extension (Re: [cc-tab] *important* heads up)

[A. Pagaltzis]

* Thomas Roessler <[EMAIL PROTECTED]> [2006-09-06 11:45]:
> On 2006-09-05 15:11:22 -0700, James M Snell wrote:
> > Take, for instance, Sam Ruby's Planet feed
> > (http://planet.intertwingly.net/atom.xml).  This feed
> > consists of entries that originated from many different
> > sources, some of which may have license links, some that
> > might not.  If Sam decided to put a license link at the feed
> > level, and if license links were inherited, it would mean
> > that Sam's license would be extended over resources he may
> > have no right to license.  Obviously, that's wrong.
> 
> Obviously, that's not obvious.  Who are we to tell that Sam
> hasn't obtained the right to attach these licenses out-of-band?

That may be a good point in this instance, but an irrelevant one.

James’ points out that there may be feeds where the feed
publisher has the rights to the feed as a collection, but not to
the content of individual entries. Since these cases exist, it
would be a bad idea for the licence to inherit from the feed to
entries in it.

Whether Sam in particular is or is not in that position does not
affect the principle. He’s not, btw: he republishes my content,
but he has no permission from me to relicense it.

Regards,
-- 
Aristotle Pagaltzis // 

Re: Can/Does/Should the FeedValidator catch improperly escaped XHTML?

[A. Pagaltzis]

* James Holderness <[EMAIL PROTECTED]> [2006-09-01 01:30]:
> Encouraging people to use xhtml when they don't know enough to
> have made that decision themselves is just asking for trouble.

+1

Regards,
-- 
Aristotle Pagaltzis // 

Finally Atom: Blogger is here

[A. Pagaltzis]

Hi all,

about time, I say. In irc.freenode.org/atom, copper just linked
to , which reads:

We’ve added some additional feed options for our more
advanced users. Now you can have a feed for all the comments
on your blog, and even individual feeds for all the comments
on each separate post. We’ve also added support for the RSS
2.0 and Atom 1.0 standards.

That makes what, another few dozen million Atom 1.0 feeds?

Regards,
-- 
Aristotle Pagaltzis // 

Re: link element alternate and self

[A. Pagaltzis]

* Sylvain Hellegouarch <[EMAIL PROTECTED]> [2006-08-13 13:00]:
> Now I wonder say I have a feed. Each entry has a link element which 
> should indicate the URI of the resource. That resource being a feed 
> itself not an entry.
> 
> In that case should I use self or alternate?

`alternate`.

The purpose of `self` is to embed the URI of the feed inside the
feed, so that an aggregator knows what URI to subscribe to, even
if all it has to go by is the feed document, but not a URI.
That’s all it’s for.

> The term "equivalent" being fairly unclear in this context IMO.

Yes, the wording in the RFC is unfortunate.

Regards,
-- 
Aristotle Pagaltzis // 

Re: clarification: "escaped"

[A. Pagaltzis]

* Antone Roundy <[EMAIL PROTECTED]> [2006-07-26 16:45]:
> Or you put the whole thing in a CDATA block.

Which is the easiest option, so long as you remember the edge
case of having to turn any `]]>` sequences in the input into
`]]>]]>

Re: clarification: "escaped"

[A. Pagaltzis]

* Robert Sayre <[EMAIL PROTECTED]> [2006-07-26 01:45]:
> On 7/25/06, Bill de hÓra <[EMAIL PROTECTED]> wrote:
> >And I didn't know whether Atom code could get away with
> >escaping < and &.
> 
>  hmm
> 
> that is an XML fatal error, no doubt, as the ampersand before
> "nbsp" must be escaped.

But he did say “escaping < and &”, so it would be. I’m not sure
what Bill’s question even is.

Regards,
-- 
Aristotle Pagaltzis //