Re: Atom Export

On 05/10/2006, at 1:08 AM, James M Snell wrote: 1. Complete list of authors and categories defined With permissions, metadata, etc. Metadata like URL and email, sure. I'm not so sure about permissions. Do we do groups then? And do we try to represent permissions for actions that are not

Re: Atom Export

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

[atom-syntax] [RFC 4685] uri in xml namespace

The RFC 4685 define an xml namespace with "http://purl.org/syndication/thread/1.0";. An HTTP GET http://purl.org/syndication/thread/1.0 answer HTTP/1.x 302 Found Location: http://www.ietf.org/internet-drafts/draft-snell-atompub-feed-thread-12.txt which redirect to http://www.ietf.org/internet

Re: Atom Export

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

SPARQLing Roller

I have recently been working on adding a SPARQL end point to a test Roller weblogger server. Using the D2RQ library developed at the Freie Universität of Berlin and the Roller Weblogger software that is powering blogs.sun.com, I have put up a test server that maps Roller's mysql tables to

Re: [atom-syntax] Atom bidi

To: atom-syntax@imc.org, [EMAIL PROTECTED] Copy to: [EMAIL PROTECTED] James Snell wrote in http://www.imc.org/atom-syntax/mail-archive/msg18925.html > To: atom-syntax atom-syntax@imc.org > Subject: Atom bidi > From: James M Snell <[EMAIL PROTECTED] > Date: Fri, 13 Oct 2006 13:20:28 -0700 > As a

Re: Atom Export

On 17/10/2006, at 10:46 PM, A. Pagaltzis wrote: 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 suppor

Re: Atom Export

* 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, y

Re: [atom-syntax] [RFC 4685] uri in xml namespace

Done! - James Nicolas Krebs wrote: > The RFC 4685 define an xml namespace with > "http://purl.org/syndication/thread/1.0";. > An HTTP GET http://purl.org/syndication/thread/1.0 answer > HTTP/1.x 302 Found > Location: > http://www.ietf.org/internet-drafts/draft-snell-atompub-feed-thread-12.tx

Re: Atom Export

I agree, however, the format should be extensible enough to support broader use cases. With Atom extensibility, this is very easy to achieve without allowing the scope of the spec to creep too far. - James A. Pagaltzis wrote: > * James M Snell <[EMAIL PROTECTED]> [2006-10-04 17:30]: >> I would

Re: [atom-syntax] Atom bidi

The key challenge with using ITS in Atom is its complexity and scope. Atom simply doesn't need to do that much. - James Nicolas Krebs wrote: > [snip] > XHTML 1.0 is the only specification which is not a working draft, but its > dir attribute does not allow "lro" and "rlo" values. > > I do not

Atom Export of source text

Alastair Rankine wrote: 4. All comments and trackbacks. For each comment or trackback: a. Source text This one needs to be expanded somewhat. In particular is it: A. The text of the entry as published in an Atom feed? or B. The source of that text as it appears in the original? In Wor

Re: [atom-syntax] Atom bidi

Yves, thanks for the input, comments below. Yves Savourel wrote: > [snip] > Atom could use just the local its:dir attribute and be ITS conformant. > Ok. this is good to know. > > I noticed the values described in atompub-bidi-00 include "" and default to > it, while XHTML 1.0, XHTML 2.0, and

Re: [atom-syntax] Atom bidi

If you're going to require a separate namespace for bidi support, maybe it's best to use XHTML 1.0 and just toss out the lro and rlo values. I know I was originally pushing for those to be included, but now that I've seen how inconsistent the bdo support is in browsers I think they're probably

Re: [atom-syntax] Atom bidi

fwiw, I have no intention of reading the Snell bidi draft, or implementing what might be inside. As I've mentioned several times, I am already implementing a solution. I will document it and roll it onto the standards track as an update to RFC4287. -Rob James Holderness wrote: If you're g

Re: [atom-syntax] Atom bidi

That's certainly a strong option. - James James Holderness wrote: > > If you're going to require a separate namespace for bidi support, maybe > it's best to use XHTML 1.0 and just toss out the lro and rlo values. I > know I was originally pushing for those to be included, but now that > I've se

Re: [atom-syntax] Atom bidi

James M Snell wrote: How kind of you. Would you mind sharing some of the details with us now so that we can come to a common solution that works with more than just Firefox and Thunderbird? It'll work fine with everythign

Re: [atom-syntax] Atom bidi

How kind of you. Would you mind sharing some of the details with us now so that we can come to a common solution that works with more than just Firefox and Thunderbird? I really can't imagine that it would all that different than what I've documented and it would be silly to come up with an alte

Re: [atom-syntax] Atom bidi

Robert Sayre wrote: > [snip] > It'll work fine with everythign > Would you mind sharing some details? Is there code already in the mozilla CVS I can go look at? I have some code already written that I'd like to get checked into Abdera soon. I'd prefer that it match what other implementors are do

Re: [atom-syntax] Atom bidi

James M Snell wrote: Would you mind sharing some of the details with us now so that we can come to a common solution that works with more than just Firefox and Thunderbird? That is absurd. This message has used up my atom-syntax time for the moment, so I guess you'll have to wait, or use up

Re: [atom-syntax] Atom bidi

Robert Sayre wrote: fwiw, I have no intention of reading the Snell bidi draft, or implementing what might be inside. As I've mentioned several times, I am already implementing a solution. I will document it and roll it onto the standards track as an update to RFC4287. To be clear, I have no

Re: [atom-syntax] Atom bidi

I've modified my very preliminary impl to support the use of xhtml:dir and have checked in some code [1]. The impl is very rough and designed only to illustrate the basic behavior I have in mind. Right now, the code determines the direction of text using the following steps (in order): 1. Look

Re: [atom-syntax] [RFC 4685] uri in xml namespace

James M Snell <[EMAIL PROTECTED]> wrote >Done! Thanks.

Re: [atom-syntax] Atom bidi

On Tue, 17 Oct 2006 21:32:46 +0200, James M Snell <[EMAIL PROTECTED]> wrote: 2. Look for the xhtml:dir attribute There's no such thing. (Except perhaps with this new XHTML Modularization madness, but that's best ignored.) -- Anne van Kesteren

Re: AD Evaluation -- extensions

On 18/10/06 8:07 AM, "Lisa Dusseault" <[EMAIL PROTECTED]> wrote: > Extensions > > When the client puts extension elements in a MER, MUST the server store those > unrecognized extension elements?  I think the answer to this is actually that > servers often do not and should not be required to do

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

Some comments... largely written up in terms of what my working assumptions have been. We'll see how things match up with what others on the list are thinking. - James Lisa Dusseault wrote: > [snip] > *High-level comments, summarizing comments* > > - The mechanism for creating a media resourc

Re: [atom-syntax] Atom bidi

I know there's no such thing :-)... which is precisely why the code I implemented is temporary and experimental :-). - James Anne van Kesteren wrote: > On Tue, 17 Oct 2006 21:32:46 +0200, James M Snell <[EMAIL PROTECTED]> > wrote: >> 2. Look for the xhtml:dir attribute > > There's no such thin

Re: AD Evaluation -- extensions

That "bucket" already exists in the form of the app:control element. ... ... ... ... - James Eric Scheid wrote: > [snip] > We did at one time discuss providing a bucket container specifically for the > latter, with the assumption that extensions outside the

Re: [atom-syntax] Atom bidi

Well I'm glad somebody pointed it out because I certainly missed it. Anyway, for now I'm just checking for an unprefixed dir attribute. If and when RFC 4287 is ever updated I'll ammend my code accordingly. Regards James James M Snell wrote: I know there's no such thing :-)... which is preci

Re: AD Evaluation -- extensions

Yes, absolutely, a way to distinguish extensions-to-the-entry from extensions-for-the-feed would be great, even if there's a possibility that the server would reject one or both. I hadn't even considered that, must have missed that discussion. Client-to-client extensions (metadata or ma

Re: [atom-syntax] Atom bidi

Yeah, for now I'm going to keep this bidi code off in an out of the way corner in the Abdera CVS until there's any more movement. Now that I've addressed a short term need I've had on my list for a while, I'll be holding off at least a few weeks to see what Sayre comes up with before deciding whe

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

I also noticed the split that Lisa mentions when reviewing the draft. I agree that they're not always separate, but it should be pointed out that they can be separate. I didn't see any mechanism to discover what the URI of the "normal" feed is, beyond a link/@rel=alternate in the collectio

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

Given that folks are already accustomed to using alternate links to discover subscription feeds, I think it would be reasonable for us to include some statement that within a collection feed, an alternate link with a type of "application/atom+xml" SHOULD be used to point to the public representati