Subject: A small suggestion for the Atom draft(s)

From: [email-masked]
Date: Fri, 29 Oct 2004 22:38:36 -0400

This is a suggestion to aid in the promotion and adoption of Atom, once the 
drafts are in a good spot. I feel it would be a good idea to include XSL 
transforms in the document that can transform Atom into the various flavors 
of RSS.   This would aid some developers, who could put a "transform 
incoming Atom to RSS" wrapper around their existing RSS-based code by 
simply invoking an XSL processor with the appropriate stylesheet.  This 
would allow developers to adopt a form "support" for Atom almost 
immediately, but allowing them more time to develop "native" support for 
Atom where they would exploit the richer metadata tags in Atom.  I'm not an 
XML expert, but it seems to me that Atom tags contain everything you would 
need to create RSS via a simple template-based transformation.

Tim Hare
Interested Bystander, Non-Inc.

---

From: Paul Hoffman / IMC <[email-masked]>
Date: Fri, 29 Oct 2004 20:39:15 -0700

At 10:38 PM -0400 10/29/04, [email-masked] wrote:
>This is a suggestion to aid in the promotion and adoption of Atom, 
>once the drafts are in a good spot. I feel it would be a good idea 
>to include XSL transforms in the document that can transform Atom 
>into the various flavors of RSS.   This would aid some developers, 
>who could put a "transform incoming Atom to RSS" wrapper around 
>their existing RSS-based code by simply invoking an XSL processor 
>with the appropriate stylesheet.  This would allow developers to 
>adopt a form "support" for Atom almost immediately, but allowing 
>them more time to develop "native" support for Atom where they would 
>exploit the richer metadata tags in Atom.  I'm not an XML expert, 
>but it seems to me that Atom tags contain everything you would need 
>to create RSS via a simple template-based transformation.

This is not part of what we want to do with the Atom core, but it is 
certainly an interesting project for someone to do on their own. If 
you do it, by all means let the WG know!

--Paul Hoffman, Director
--Internet Mail Consortium

---

From: Danny Ayers <[email-masked]>
Date: Sat, 30 Oct 2004 12:39:37 +0200

I do think this is a good idea, and would hope to see something like
this at least as informative material associated with the spec. I'd
say it was closer to the core than Paul suggests, as the charter says:

"The working group's primary focus will be on delivering an
interoperable format and corresponding protocol..."

Interop in the present environment means being able to bridge to RSS
systems. XSLT should offer a good approach.

Having said all that,

> it seems to me that Atom tags contain everything you would

It's definitely something that needs to be looked at in more detail,
but I don't think this can be done right now -

Atom => RSS 1.0 will almost certainly need extensions to the RSS
(something which should come out of the work Henry and I have been
doing with RDF/OWL)

RSS 1.0 => Atom will be lossy, because of the lack of extension
support in Atom (e.g. try a Nature feed: http://www.nature.com/rss)

Atom => RSS 2.0 again will be lossy without extensions (for RSS), but
the ambiguity around content markup means this will probably be
indeterminate no matter what, so a usable hack is probably the best
bet.

RSS 2.0 => Atom should be most straightforward, assuming we find a
good strategy for interpreting content with markup.

RSS 0.9 is RDF/XML, so can be mapped as RSS 1.0. RSS 0.91 and the
other 57 varieties are probably best considered as marginally invalid
RSS 2.0.

Cheers,
Danny.

-- 

http://dannyayers.com

---

From: Dave Johnson <[email-masked]>
Date: Sat, 30 Oct 2004 10:53:12 -0400

> systems. XSLT should offer a good approach.

Yes, what better way to "how one migrates from the various RSS versions 
to the Atom syndication feed format" as the charter says.

> support in Atom (e.g. try a Nature feed: http://www.nature.com/rss)

Are extensions NOT part of the Atom charter?

- Dave

--
Dave Johnson
http://rollerweblogger.org/page/roller

---

From: "Scott Hollenbeck" <[email-masked]>
Date: Sat, 30 Oct 2004 11:23:14 -0400

> Are extensions NOT part of the Atom charter?

The answer is right in the charter [1] itself:

"Extension development is not included in this charter. The working
group will consider the need to either close or to modify the charter
and document extensions once the core document set has been approved
by the IESG."

-Scott-
atompub area advisor

[1]
http://www.ietf.org/html.charters/atompub-charter.html

---

From: Henry Story <[email-masked]>
Date: Sat, 30 Oct 2004 17:17:36 +0200

Yes, extensions are part of the Atom Charter, but the atom list seems 
to have come to a standstill on the issue. Any attempt to get the power 
of RDF enabled, which would be needed for RSS1.0 conversion, is heavily 
opposed by some. As a result there is no agreement on the issue yet, as 
far as I can tell.

Henry

---

From: Robert Sayre <[email-masked]>
Date: Sat, 30 Oct 2004 11:22:31 -0700

> Are extensions NOT part of the Atom charter?

Of  course they are. Call me crazy, but I think it *might* be possible 
to extend Atom with those wonderful Nature extensions.
That said, we haven't nailed down our extension policy yet, so we'll 
continue to get inquiries like this until we do.

Robert Sayre

---

From: Dave Johnson <[email-masked]>
Date: Sat, 30 Oct 2004 11:38:22 -0400

oops, I was looking at the old charter
http://www.intertwingly.net/wiki/pie/IetfCharter

Thanks,
- Dave

---

From: Henry Story <[email-masked]>
Date: Sat, 30 Oct 2004 17:45:56 +0200

Yes but just above is says:

"The working group's primary focus will be on delivering an
interoperable format and corresponding protocol; it is expected
that all but the most basic, generic metadata and functions will be
accommodated through extensions, rather than in the core documents."

So how can you deliver an interoperable format if you don't allow or 
provide a mechanism to allow for extensions?

Clearly the working group is not going to build the extensions 
themselves, which is what the text you quote is saying. But the text 
above says it has to provide for those to be developed. An RDF based 
format would automatically satisfy both.

Henry Story

---

From: "Scott Hollenbeck" <[email-masked]>
Date: Sat, 30 Oct 2004 12:05:26 -0400

> So how can you deliver an interoperable format if you don't 
> allow or provide a mechanism to allow for extensions?

Extensibility is part of the charter.  Extension development is not.  It
wasn't my intention to imply that the latter excluded the former.

The question you asked, though, implies that extensibility is required for
interoperability.  I don't agree, but that's not the point of this thread
and most likely because we have different thoughts about what
"interoperable" means.

-Scott-

---

From: Paul Hoffman / IMC <[email-masked]>
Date: Sat, 30 Oct 2004 09:22:53 -0700

At 12:39 PM +0200 10/30/04, Danny Ayers wrote:
>systems.

Um, no it doesn't, and it never has. It's a bit late to start 
redefining basic terms in the charter.

"Interoperable" means that anyone picking up our spec can make a 
product that interoperates with other product that follows the spec.

At 10:53 AM -0400 10/30/04, Dave Johnson wrote:
>Yes, what better way to "how one migrates from the various RSS 
>versions to the Atom syndication feed format" as the charter says.

Are we both looking at the same charter? I see nothing on 
<http://www.ietf.org/html.charters/atompub-charter.html> that says 
that.

--Paul Hoffman, Director

---

From: Henry Story <[email-masked]>
Date: Sat, 30 Oct 2004 18:24:04 +0200

> wasn't my intention to imply that the latter excluded the former.

Ok. I agree with that position.

> and most likely because we have different thoughts about what

Yes, I agree. I wrote my question a little too fast. The relation 
between extensibility and interoperability is not what supports the 
statement that extensibility is part of the charter. What supports it 
is the following text:

"it is expected that all but the most basic, generic metadata and 
functions will be
accommodated through extensions, rather than in the core documents."

I now understand that you were responding literally to the form of Dave 
Johnson's question. I understood him to mean "Is extensibility not part 
of the charter?"
It was the context of the question, as a response to Danny's pointing 
out that translating RSS1.0 into Atom would be lossy because of lack of 
"extension support" (= extensibilty) that makes me think that 
interpretation was the correct one.

But it's not surprising to find oneself tripped up for these oversights 
in a syntax list :-)

Henry

---

From: Walter Underwood <[email-masked]>
Date: Sat, 30 Oct 2004 09:45:20 -0700

> to the Atom syndication feed format" as the charter says. 

I don't think that XSLT is a "better way" to document the mappings
between the formats. A big table with comparable elements and
notes would be a lot more informative than wading through multiple
XSLT files.

XSLT would be an excellent way to demonstrate interop, but not to
describe how to migrate.

And of course, running code is always a good thing for IETF specs,
so the XSLT is quite welcome.

wunder
--
Walter Underwood
Principal Architect, Verity

---

From: Dare Obasanjo <[email-masked]>
Date: Sat, 30 Oct 2004 10:15:06 -0700 (PDT)

> provide a mechanism to allow for extensions?

(a) No one has said that Atom won't have an extension
mechanism. All I've heard people argue is that
RDF-based extensibility will be the basis of it. 

(b) The ability to define extensions and
interoperability are orthogonal. Does the fact that
there is no extension mechanism for XML 1.0 mean it
isn't interoperable? 

=====
THINGS TO DO IF I BECOME AN EVIL OVERLORD #222
I reserve the right to execute any henchmen who appear to be a little too intelligent, powerful, or devious. However if I do so, I will not at some subsequent point shout "Why am I surrounded by these incompetent fools?!"

__________________________________
Do you Yahoo!?
Read only the mail you want - Yahoo! Mail SpamGuard.
http://promotions.yahoo.com/new_mail

---

From: Danny Ayers <[email-masked]>
Date: Sat, 30 Oct 2004 19:18:47 +0200

> product that interoperates with other product that follows the spec.

Taking the narrowest possible interpretation is as much redefining
basic terms as my pragmatic remark. But Atom doesn't exist in a void.
There are other systems with which it will be desirable to
interoperate. Most syndication systems currently use RSS. A large
proportion of the people picking up our spec will be wanting to add
Atom capability to existing RSS-capable systems. What will interop
mean to them?

I don't see any conflict between interop between systems based on the
Atom format and protocol and interop between systems on the Web at
large. You will be able to base shiny new VPNs on Atom, just as you
will be able to extend existing systems to interoperate using Atom.
For the latter, and in the interests of encouraging adoption of Atom,
XSLT-based interfaces will probably be useful.

Cheers,
Danny.

-- 

http://dannyayers.com

---

From: Danny Ayers <[email-masked]>
Date: Sat, 30 Oct 2004 19:35:50 +0200

> XSLT would be an excellent way to demonstrate interop, but not to

But if the XSLT is accurate, it can do more than describe how to
migrate, it can implement the migration. This isn't hypothetical -
some of the input processing I had for an app [1] used XSLT to
normalise the RSS 0.9x input to RSS 1.0. An Atom (0.3)  => RSS 1.0
stylesheet became available from a third party [2]. A minor config
change later I had Atom support.

Cheers,
Danny.

[1] http://ideagraph.net/
[2] http://purl.org/net/syndication/subscribe/feed-rss1.0.xsl

-- 

http://dannyayers.com

---

From: Dave Johnson <[email-masked]>
Date: Sat, 30 Oct 2004 13:38:46 -0400

On Oct 30, 2004, at 12:45 PM, Walter Underwood wrote:
>> versions

Yes, you are correct and I take that back. XSLT is not necessarily the 
best way to document the mappings. However it does have the benefit of 
being "working code."

- Dave

---

From: Paul Hoffman / IMC <[email-masked]>
Date: Sat, 30 Oct 2004 10:41:05 -0700

At 7:18 PM +0200 10/30/04, Danny Ayers wrote:
>basic terms as my pragmatic remark.

No, it's not. I am using the definition that is most common in the 
IETF, the forum for this standardization work. If you want to use a 
different definition, feel free to do so in a different forum.

>But Atom doesn't exist in a void.
>Atom capability to existing RSS-capable systems.

Of course. And you can help them do that with a non-WG document 
describing how to do so. I already proposed that yesterday.

>  What will interop

I don't know, and neither do you. Are you suggesting that we spend WG 
time pondering this in case we want to change our charter? Such 
pondering, of course, comes at the expense of doing the real work we 
still have ahead of us.

>XSLT-based interfaces will probably be useful.

Maybe so; prove it. Write an individual Internet Draft. If folks 
agree with you, then it might become an RFC outside the Working Group.

--Paul Hoffman, Director

---

From: Danny Ayers <[email-masked]>
Date: Sat, 30 Oct 2004 20:13:29 +0200

> different definition, feel free to do so in a different forum.

If you can point me to the defining RFC, I will accept the definition.
Otherwise I will continue to use what I consider to be an appropriate
definition to facilitate the ends of this WG, in my role as a member
of this WG.

> describing how to do so. I already proposed that yesterday.

I'm sure a considerable amount of the material which will serve the
end-users of this WG's chartered deliverables will appear outside of
those deliverables. But it is worth bearing in mind that the more
aspects of syndication are pushed to one side, the less relevance the
WG will have to the end-users. That isn't necessarily a bad thing.

> pondering, of course, comes at the expense of doing the real work we

I'm not suggesting any changes to the charter. 

> agree with you, then it might become an RFC outside the Working Group.

Politics isn't really my medium.

Cheers,
Danny.

-- 

http://dannyayers.com

---

From: Walter Underwood <[email-masked]>
Date: Sat, 30 Oct 2004 18:15:10 -0700

> definition to facilitate the ends of this WG, in my role as a member

Interoperability concerns implementations of the specification.

MUST, SHOULD, and friends are defined in terms of that sort of
interoperability. Any other definition is contrary to genera
practice in IETF specifications.

If you want to look for definitions, start with Tao of the IETF
and also try RFC 2360, "Guide for Internet Standards Writers".

wunder

---

From: Danny Ayers <[email-masked]>
Date: Sun, 31 Oct 2004 10:14:40 +0100

> and also try RFC 2360, "Guide for Internet Standards Writers".

Thanks Walter. The second paragraph of the RFC makes the expected
usage of the word clear, and I'll be glad to follow that definition in
the context of IETF discussions. I apologise for any confusion I may
have caused.

It isn't the only definition available (check FOLDOC and Wikipedia),
and I did actually quote the spec in my post - if there wasn't scope
for interpretation, then any contradiction in my remarks would have
been apparent, not requiring condemnation. Clearly there is scope for
misinterpretation of such language for those of us not immersed in
IETF arcana. But I'm sure the chairs will remain vigilant when it
comes to clearing up such errors.

Cheers,
Danny.

-- 

http://dannyayers.com

---

From: Paul Hoffman / IMC <[email-masked]>
Date: Sun, 31 Oct 2004 08:50:22 -0700

At 10:14 AM +0100 10/31/04, Danny Ayers wrote:
>But I'm sure the chairs will remain vigilant when it

Will do.

And this co-chair will also keep reminding people that it's *just 
fine* to write Internet Drafts that are not WG documents for things 
that are outside the scope of the WG. The WG charter is only supposed 
to constrain the discussion and products within the WG, not on the 
whole Internet. Some of the most useful RFCs are individual 
submissions that extend, help, or just explain WG-generated RFCs.

--Paul Hoffman, Director