Re: Atom Bidi Draft Update - Informal Last Call

2007-03-28 Thread James M Snell

I'd be fine with this also.  There's no immediate rush for this but it
would be excellent if implementors could start taking a look at it.

- James

Franklin Tse wrote:
 I don't think we are in a hurry to move the draft to an RFC, so, can the 
 draft be held in the Draft stage and issue a call for implementations? The 
 future of the draft should be based on the implementation reports received.
 
 Franklin
 
 - Original Message -
 From: Martin Duerst [EMAIL PROTECTED]
 To: James M Snell [EMAIL PROTECTED]; Franklin Tse [EMAIL PROTECTED]
 Cc: atom-syntax atom-syntax@imc.org; atom-protocol [EMAIL PROTECTED]
 Sent: Wednesday, March 28, 2007 15:29
 Subject: Re: Atom Bidi Draft Update - Informal Last Call
 
 At 02:25 07/03/23, James M Snell wrote:
 It is not year clear if there has been enough independent implementation
 of the specification to justify publishing it as a proposed standard.
 There is no need for implementations when going to Proposed Standard
 (of course, they never hurt). There is a well-defined need when going
 from Proposed Standard to Draft Standard, but that's way in the future.

 Regards, Martin.


 #-#-#  Martin J. Durst, Assoc. Professor, Aoyama Gakuin University
 #-#-#  http://www.sw.it.aoyama.ac.jp   mailto:[EMAIL PROTECTED] 


 



Re: Atom Bidi Draft Update - Informal Last Call

2007-03-28 Thread James M Snell

Yeah, I know, but I personally have a preference towards having more
implementations available... especially since we're talking about a
draft that updates the core Atom spec with a new attribute.

- James

Martin Duerst wrote:
 At 02:25 07/03/23, James M Snell wrote:
 It is not year clear if there has been enough independent implementation
 of the specification to justify publishing it as a proposed standard.
 
 There is no need for implementations when going to Proposed Standard
 (of course, they never hurt). There is a well-defined need when going
 from Proposed Standard to Draft Standard, but that's way in the future.
 
 Regards, Martin.
 
 
 #-#-#  Martin J. Durst, Assoc. Professor, Aoyama Gakuin University
 #-#-#  http://www.sw.it.aoyama.ac.jp   mailto:[EMAIL PROTECTED] 
 
 



Atom Bidi Draft Update - Informal Last Call

2007-03-22 Thread James M Snell

I have posted an updated version of the Atom Bidi Draft.  The only
significant difference is a notice about direction guess algorithms.

  http://www.ietf.org/internet-drafts/draft-snell-atompub-bidi-03.txt

I have implemented support for this specification in Abdera and in IBM's
updated internal blogging environment.

The specification adds a new attribute dir to the set of common
attribute attributes within the Atom namespace.  The dir attribute
specifies the default directionality of language-sensitive text within
an Atom document.

example,

entry xmlns=http://www.w3.org/2005/Atom; dir=rtl
  ...
/entry

At this point, I intend to request a formal last call on the document
and recommend it for publication as an experimental or informational draft.

Feedback is requested.

- James



Re: Atom Bidi Draft Update - Informal Last Call

2007-03-22 Thread James M Snell

It is not year clear if there has been enough independent implementation
of the specification to justify publishing it as a proposed standard.

- James

Franklin Tse wrote:
 James,
 
 Why are you going to recommend that for publication as an experimental or 
 informational draft, but not a Proposed Standard?
 
 Franklin Tse
 
 - Original Message -
 From: James M Snell [EMAIL PROTECTED]
 To: atom-syntax atom-syntax@imc.org; atom-protocol [EMAIL PROTECTED]
 Sent: Friday, March 23, 2007 00:59
 Subject: Atom Bidi Draft Update - Informal Last Call
 
 I have posted an updated version of the Atom Bidi Draft.  The only
 significant difference is a notice about direction guess algorithms.

  http://www.ietf.org/internet-drafts/draft-snell-atompub-bidi-03.txt

 I have implemented support for this specification in Abdera and in IBM's
 updated internal blogging environment.

 The specification adds a new attribute dir to the set of common
 attribute attributes within the Atom namespace.  The dir attribute
 specifies the default directionality of language-sensitive text within
 an Atom document.

 example,

 entry xmlns=http://www.w3.org/2005/Atom; dir=rtl
  ...
 /entry

 At this point, I intend to request a formal last call on the document
 and recommend it for publication as an experimental or informational draft.

 Feedback is requested.

 - James


 



Autodiscovery Draft

2007-03-19 Thread James M Snell

I'm assuming that since there was no additional expressed interest in
moving forward with the Atom autodiscovery draft that it's not going to
go anywhere.  My current intention is to go ahead and let it expire
again without any further modifications.

- James



Re: Autodiscovery Draft

2007-03-19 Thread James M Snell

The autodisco draft originally authored by Mark Pilgrim and resurrected
by me late last year.

http://www.ietf.org/internet-drafts/draft-snell-atompub-autodiscovery-00.txt

- James

Jan Algermissen wrote:
 James,
 
 what draft do you refer to?
 
 Thanks,
 Jan
 
 On 19.03.2007, at 20:50, James M Snell wrote:
 

 I'm assuming that since there was no additional expressed interest in
 moving forward with the Atom autodiscovery draft that it's not going to
 go anywhere.  My current intention is to go ahead and let it expire
 again without any further modifications.

 - James

 
 



Re: Autodiscovery Draft

2007-03-19 Thread James M Snell



John Panzer wrote:
 [snip]
 Also, is there a standard way to discover the collection associated with
 a feed?  (Given that, if there is an IETF or WHAT-WG way to discover
 feeds, there's an obvious way to discover collections... but I'm not
 clear on what that would be.  I do think that collection autodisco is
 important.)

An app:collection element can appear within atom:feed and atom:source
elements.

- James



Re: Representing bookmarks

2007-03-09 Thread James M Snell

For Lotus Connections we're representing bookmarks as

entry
  id.../id
  title.../title
  authorname.../name/author
  content.../content
  link href={bookmark url} /
  category term={tag} /
  updated.../updated
/entry

This works for everything we need.

- James

Brendan Taylor wrote:
 I'd like to represent bookmarks using Atom, so that I can manipulate
 them using the Publishing Protocol.
 
 I discussed this briefly with Aristotle on IRC. He has an XSLT which
 transforms del.icio.us into Atom [1]; (the important bit of) the entries
 it produces look like this:
 
   entry
 titleThe Atom Syndication Format/title
 summaryAn alternative to RSS2./summary
 link href=http://www.ietf.org/rfc/rfc4287/
 category term=rfc/
   /entry
 
 (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. 
 
 Linking to the RFC as an alternate representation of the entry suggests
 that the entry and the RFC issue from the same source. (ie. if the
 entry appears in a feed that lists me as an author it implies that
 RFC4287 was written by me)
 
 So, what's the right way?
 
 1: http://plasmasturm.org/code/delicious-atom/



Re: Current and permalink link rel values

2007-02-23 Thread James M Snell

+1.

Antone Roundy wrote:
 [snip]
 So you couldn't keep both as alternate links.  In my opinion, you
 should use the second one (the longer lasting one) only, and omit the
 first (which is going to become invalid as soon as the entry falls off
 the page anyway -- anyone who used it to get to your page and bookmarked
 it, and anyone who follows it from a cached copy of your feed isn't
 going to be able to find the entry without a lot of needless digging
 through your archives). You should have a link to
 http://www.cafeconleche.org/ at the feed level.  While that won't link
 directly to that entry, it'll get people to it as long as it's on that
 page.
 
 



Re: Current and permalink link rel values

2007-02-23 Thread James M Snell

Last I had checked (last spring) it was a mess.  Some readers picked the
first alternate link in the document; some readers picked the last
alternate link in the document; some readers picked the first link in
the document regardless of it's rel value; some readers picked the last
link in the document regardless of rel value; one reader would even
completely ignore atom:source elements in the entry and would choose
links from that depending on where the atom:source was placed in the
entry.  Hopefully it's gotten better since but I don't know for sure.

- James

Elliotte Harold wrote:
 [snip]
 
 Does anyone know how feed readers actually do choose among multiple
 possible links in an entry?
 



IBM IPR Disclosure

2007-02-15 Thread James M Snell

All,

As a general FYI, IBM just filed a blanket IPR disclosure [1] relating
to the activity of the Atompub WG.  Before any misinformation starts
going around about this I thought it would be a good idea to give y'all
a heads up.

As of right now IBM has NO KNOWN patents or applications for patents
that read on the Atom specs.  However, as is well known, IBM has a
massive IPR portfolio and it would take a very long time and cost a lot
of money for us to dig through 'em all to know for certain.  Rather than
spend the time and energy doing that, IBM has agreed to a blanket
commitment to Royalty Free terms for any IPR that reads on the Standards
Track specifications produced by the atompub Working Group.

Again, I want to reiterate that there are no patents we are currently
aware of nor are there any applications in progress that we are
currently aware of.

There are basically two reasons we are doing this:

1. We think the Atom Syndication Format and the Atom Publishing Protocol
are really important.

2. We want anyone to be able to implement Atom without any fear of
patent hell (and we're really hoping that others agree).

I must add that I am not a IPR expert by any stretch of the imagination.
 If you have questions, please direct them to me and I will answer what
I can or I will forward them on to our IP Law experts.

- James


[1] https://datatracker.ietf.org/public/ipr_detail_show.cgi?ipr_id=804



Re: I-D ACTION:draft-ietf-atompub-protocol-13.txt

2007-02-13 Thread James M Snell

I was going to say ship it but I noticed one major problem: the
app:categories element is defined twice: once in section 7 and again in
8.2.5. I realize that these are different contexts (e.g. categories as a
standalone doc vs. an element in the service doc) but it's entirely
unnecessary to define 'em in both places.

- James

[EMAIL PROTECTED] wrote:
 A New Internet-Draft is available from the on-line Internet-Drafts 
 directories.
 This draft is a work item of the Atom Publishing Format and Protocol Working 
 Group of the IETF.
 
   Title   : The Atom Publishing Protocol
   Author(s)   : B. de Hora, J. Gregorio
   Filename: draft-ietf-atompub-protocol-13.txt
   Pages   : 59
   Date: 2007-2-13
   
 The Atom Publishing Protocol (APP) is an application-level protocol
for publishing and editing Web resources.  The protocol is based on
HTTP transport of Atom-formatted representations.  The Atom format is
documented in the Atom Syndication Format [RFC4287].
 
 A URL for this Internet-Draft is:
 http://www.ietf.org/internet-drafts/draft-ietf-atompub-protocol-13.txt
 [snip]



Re: Query re: support of Media RSS extensions inside Atom feeds

2007-02-12 Thread James M Snell

I'd be all for it assuming it didn't go off in the weeds.

- James

Ernest Prabhakar wrote:
 
 On Feb 9, 2007, at 9:23 PM, John Panzer wrote:
 Does anyone know of any issues with placing Yahoo! Media RSS
 extensions (which seem to fit the requirments for Atom extensions to
 me) inside an Atom feed?  Secondarily
 
 A year or two ago there was discussion of doing an IETF working group to
 add Media RSS (or equivalent) extensions to Atom.
 
 Is there any interest in reviving that effort?
 
 -- Ernie P.
 
 On Feb 10, 2007, at 10:51 AM, Antone Roundy wrote:
 

 , do feed readers in general recognize MRSS inside either Atom or
 RSS?  Looking for field experience/implementor intentions here.

 CaRP partially supports Media RSS in RSS (it doesn't directly support
 Atom at all, and Grouper, the companion script that converts Atom to
 RSS for it doesn't yet have Media RSS support, though I may add it in
 the next update).  It only looks at elements pointing to images
 (@type=image/*) and their types, heights and widths.  I added this
 in response to user requests--primarily, I believe, for use with
 Flickr feeds.

 Antone

 
 



Re: Query re: support of Media RSS extensions inside Atom feeds

2007-02-10 Thread James M Snell

That's a big assumption.  The only reason I added it to Abdera was to
prove a point about being able to support RSS extensions in Atom.  I
haven't come across any implementation that makes use of the extensions.

- James

James Holderness wrote:
 [snip]
 That said, I know there are feed libraries that support it to some
 extent (in RSS at least) so there must be some people using it.
 
 Regards
 James
 
 



Re: Query re: support of Media RSS extensions inside Atom feeds

2007-02-09 Thread James M Snell

I'm not sure if there are any feed readers that support MRSS in Atom but
I don't see any reason why it wouldn't work.  A while back I implemented
minimal support for the MRSS extensions in Abdera with very little
difficulty.

- James

John Panzer wrote:
 Does anyone know of any issues with placing Yahoo! Media RSS extensions
 (which seem to fit the requirments for Atom extensions to me) inside an
 Atom feed?  Secondarily, do feed readers in general recognize MRSS
 inside either Atom or RSS?  Looking for field experience/implementor
 intentions here.
 
 Thanks,
 -- 
 
 Abstractioneer http://feeds.feedburner.com/aol/SzHOJohn Panzer
 System Architect
 http://abstractioneer.org



Re: Best practice for linking to child feeds

2007-01-22 Thread James M Snell

RFC 4685 - http://www.ietf.org/rfc/rfc4685.txt

- James

Becker, Matthew R wrote:
 Given a feed of discussion board topics, how do you show that an Atom
 entry representing a topic has a related child feed representing the
 posts for that topic? I was looking at the rel attribute of the link
 element and I do not see a valid value of child.  I thought I saw this
 in an older draft. What is the recommended way to handle a hierarchy of
 related feeds?
 
 Thanks,
 
 Matt.
 



Re: Quoting type parameter value allowed? - Was: I-D ACTION:draft-ietf-atompub-typeparam-00.txt

2007-01-19 Thread James M Snell

+1. The way I read it the quotes do not matter.

- James

Bob Wyman wrote:
 On 1/19/07, *Andreas Sewe* [EMAIL PROTECTED]
 mailto:[EMAIL PROTECTED] wrote:
 So, it looks like that quoting the type parameter's values is no
 longer allowed;
 Are the quotes part of the parameter value? Or, are quotes merely
 delimiters of the value? If RFC045 is read to indicate that the quotes
 are delimiters, then it would not be in conflict with RFC4288 since in
 both cases, feed would be interpretted as being the value 'feed'...
 
 bob wyman
 



Re: Inheritance of license grants by entries in a feed

2007-01-15 Thread James M Snell

In the current draft, license links *are* inherited.

Thomas Roessler wrote:
 On 2007-01-14 20:04:12 +, David Powell wrote:
 
 [snip]
 Be that as it may -- the atom:rights element *is* inherited, and I'd
 expect some major confusion if a atom:license element wasn't.
 



Atom license extension - final stages

2007-01-14 Thread James M Snell

All,

The Atom license extension is continuing to move forward.  Based on some
last call comments that were received, I have decided to add two
additional items to the spec:

 1. An equivalence rule for license URIs

 2. A IANA registry for common license URIs

Over the next week I'll be working up the details of each and will be
posting a new draft, likely by next Friday.

- James



Re: I-D ACTION:draft-ietf-atompub-typeparam-00.txt

2007-01-11 Thread James M Snell

+1

Andreas Sewe wrote:
 
 Sylvain Hellegouarch wrote:
 Hugh Winkler wrote:
 The draft makes no mention of file extensions.

 Server software responsible for inserting correct Content-type header
 can *possibly* set the correct value when serving a file, if the
 type=entry and type=feed documents have distinct file extensions.
 (I think this server behavior is an accident of implementation,
 because I've never encountered a mime type parameter in any
 mime.types file or in the Windows registry).

 Fair point but it has been extensively discussed in a previous thread
 and it appears that few people were keen on adding an entirely new media
 type. While the type parameter may not be ideal it seemed to be lest
 disruptive. I personally agree that a new media type would enforce the
 correct and native distinction between entry and feed but most people
 who have participated didn't feel like there was such a string
 requirement.
 
 The OP has a (different) point, though: Recommending distinct file
 extensions for application/atom+xml; type=entry and
 application/atom+xml; type=feed is worthwhile.
 
 If, e.g., the mime.types shipped with Apache already contains
 appropriate entries, this would aid the fast adoption of the new,
 parameterized application/atom+xml. Hence it would be worthwhile to
 include file extension recommendations in the I-D.
 
 Regards,
 
 Andreas
 
 



Re: Type parameter implementation

2007-01-09 Thread James M Snell

I've added very preliminary support for it to Abdera.  Nothing major,
just a bit that detects the root node and outputs the media type
according and a bit that checks to see if the media type specifically
identifies an entry.  Once we're a bit further down the path towards
finalizing the spec, I'll add support to the server component for
checking the type.

- James

Sylvain Hellegouarch wrote:
 Hi folks,
 
 Wth the first version of the type parameter draft [1] recently released
 by James, I was wondering if implementors had started implementing it
 either in their Atom consumer or APP server/client?
 
 Or is it to be considered too soon?
 
 - Sylvain
 
 [1] http://www.ietf.org/internet-drafts/draft-ietf-atompub-typeparam-00.txt
 
 



Re: Fwd: Atom format interpretation question

2007-01-07 Thread James M Snell

Ahhh... a slight ambiguity presents itself.  The treatment of text/
types in RFC 4287 is a bit underspecified.  I've always worked off the
assumption that text/* types do not require base64 encoding (that's what
Abdera expects).

- James

James Holderness wrote:
 
 Sam Ruby wrote:
 James M Snell wrote:
 If you want to use the text/vnd.IPTC.NewsML media type to
 identify the type of XML, then you'd have to escape the markup and treat
 it like text.

 s/escape/Base64/
 s/like text/as binary/
 
 Are you sure? From RFC 4287, section 4.1.3.3:
 
 5.  If the value of type begins with text/ (case insensitive), the
 content of atom:content MUST NOT contain child elements.
 6.  For all other values of type, the content of atom:content MUST be
 a valid Base64 encoding, as described in [RFC3548], section 3.
 
 In this case the type begins with text/ so surely rule 5 applies, not
 rule 6.
 
 Regards
 James
 
 



Atom Bidi Attribute - *Unofficial* Last Call

2007-01-05 Thread James M Snell

The Atom Bidi Attribute specification [1] updates RFC 4287 by adding a
new 'dir' attribute to the set of atomCommonAttributes.  The purpose is
to provide a means of defining the base directionality of
direction-neutral characters in Language-Sensitive text.  The rationale
is that direction-guessing schemes based on language and character
properties, while definitely useful and correct a lot of the time, are
inherently limited and flawed.  We need a way of explicitly specifying
the directionality.

Prior to moving this forward with the IESG, however, I wanted to issue
an informal last call here on the list to solicit feedback.

Note: Apache Abdera currently implements support for this attribute in
an optional and experimental extension module.

- James

[1] http://www.ietf.org/internet-drafts/draft-snell-atompub-bidi-02.txt



Re: Additional 'namespace' attribute on content element?

2007-01-04 Thread James M Snell



Jan Algermissen wrote:
 Hi,
 
 on the NewsML list, an issue came up that due to they lack of a MIME type 
 for NewsML using NewsML as Atom content is somewhat problematic[1]; I think 
 this is the case with most of the more interesting XML applications out there.
 
 Is there any chance to extend/revise Atom to allow an attribute on the 
 content 
 element that allows to specify the namespace of XML content given the MIME 
 type 
 is declared as application/xml or text/xml?
 
 Actually, there is no posibility to do this as an Atom extension, is there?
 

Of course this can be done as an extension. The bigger problem is that
NewsML doesn't have an XML Namespace to declare.  At least, I don't see
one in version 1.2

- James



Re: I-D ACTION:draft-ietf-atompub-typeparam-00.txt

2007-01-04 Thread James M Snell

Hey Bob,

I have no problem with the rewording. Just waiting to see what others
may have to say about it.

- James

Bob Wyman wrote:
 
 This document looks good on an initial quick read -- with one possible
 exception. It says:
 
 Atom processors that do recognize the parameter SHOULD
 detect and report inconsistencies between the parameter's
 value and the actual type of the document's root element.
 
 This would seem to be creating a directive concerning behavior which
 is not directly related to interoperation between systems. (I'm
 assuming that the destination of the reports is the user of the
 application, a log file, or something like that.) Thus, it seems to me
 that it might be inappropriate to use the SHOULD word since IETF apps
 are supposed to be focused on interoperation and are supposed to avoid
 constraining application behavior unnecessarily. May I suggest that
 you rewrite this sentence in a manner similar to that below:
 
 It is strongly recommended that Atom processors that do recognize the
 parameter detect and report 
 
 bob wyman
 
 



Re: Fwd: Atom format interpretation question

2007-01-04 Thread James M Snell

If it's well-formed XML then I'd think dropping it into atom:content
using type=application/xml would be acceptable.  You'd just end up
losing that bit of semantic metadata that tells you exactly what kind of
XML it is.  If you want to use the text/vnd.IPTC.NewsML media type to
identify the type of XML, then you'd have to escape the markup and treat
it like text.  If the NewsML folks want to be able to use a proper media
type to identify their stuff AND treat it as XML, they should come up
with an appropriate media type registration (e.g.
application/newsml+xml, etc).

- James

Tim Bray wrote:
 
 Begin forwarded message:
 
 From: John Cowan [EMAIL PROTECTED]
 Date: January 4, 2007 8:08:06 AM PST (CA)
 To: [EMAIL PROTECTED]
 Subject: Atom format interpretation question

 Am I right in thinking that content which is in fact in XML but
 is labeled with a media type that is neither generic XML nor
 ends in +xml cannot be included inline in an Atom entry?
 The NewsML community (which uses the registered media-type
 text/vnd.IPTC.NewsML) is concerned about this.

 -- John Cowan  [EMAIL PROTECTED]  http://ccil.org/~cowan
 Any sufficiently-complicated C or Fortran program contains an ad-hoc,
 informally-specified bug-ridden slow implementation of half of Common
 Lisp.
 --Greenspun's Tenth Rule of Programming (rules 1-9 are unknown)
 
 
 



Re: base within HTML content

2007-01-01 Thread James M Snell

-1. If there's anything we can learn from the mess that is RSS, at a
certain point feed consumers should be allowed to say simply that a
buggy feed is a buggy feed and that it falls on the responsibility of
the feed publisher to get things right.

- James

James Holderness wrote:
 [snip]
 Do you still have a copy of the feed you encountered that was using a
 base element? I'd be curious to see whether its links and images would
 fail to work if you didn't take that base into account? Because if
 that's the case, I'd recommend supporting it (i.e. the base element
 takes precedence over xml:base or however else the current base uri is
 determined).
 
 In other words, do whatever it takes to get that particular feed to
 work. This obviously isn't a common scenario, and it's arguably not a
 valid feed, so whatever you do you can't be faulted. Unless you find
 more data suggesting this is a bad idea, it seems to me it would make
 sense to at least get your one known example to work.
 
 MHO.
 
 Regards
 James
 
 



Re: Atom Entry docs

2006-12-19 Thread James M Snell

Ok, so we've had more than just a few people put up their hands and say
what Bob said.  This week I'll go ahead write up an initial draft of
this using the type param option while we wait for the co-chairs to do
their hasty consensus grab :-)

- James

Tim Bray wrote:
 [snip]
 co-chair-modeIn case you haven't noticed, the WG is hopelessly split
 between the new-media-type option and the media-type-parameter option.
 If a few people were to put up their hands and say yeah what Bob said
 your co-chairs would probably do a hasty consensus grab./co-chair-mode
 [snip]



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

2006-12-17 Thread James M Snell

Quite frankly it doesn't matter what we call anything right now. The
server gets to determine what pieces of data it's willing to handle.
Period.  If you want anything more than that, use webdav.

- James

Eric Scheid wrote:
 On 17/12/06 1:13 PM, A. Pagaltzis [EMAIL PROTECTED] wrote:
 
 * 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.
 
 wha?
 
 What music Lisa is listening to when she wrote a blog posting is meta data,
 not content, unless of course she's writing a blog posting *about* that
 particular bit of music. The music is contextual meta data, along the same
 vein as geo location of circumstance, the atom:generator involved, and even
 the atom:published date/time.
 
 Since when are we calling atom entries envelopes?
 
 e.
 
 
 



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

2006-12-16 Thread James M Snell



Tim Bray wrote:
 [snip]
 We think that APP as specified allows very good interoperability for
 basic Web-centric publish/edit operations with low overhead, and low
 demands for complexity in the client and sever implementations.   Adding
 the requirement for client-side extensibility would reduce the number of
 server implementations that would be able to advertise conformance with
 APP, even though they are perfectly capable of the highly-useful
 function possible under APP as of the current draft.
 

+1

 (It remains easy for servers to add extensions to Atom feeds and
 entries using prescribed mechanisms like adding new elements in custom
 namespaces.  )
 
 Right.  Phrased another way, the APP is highly extensible; but the
 current version requires co-operation from both client and server.  This
 seems reasonable to me.
 

+1

 It may be that I'm just having trouble accepting that the WG fully
 understands this and has still come to consensus that this is a great
 way to proceed.  Is that the case?
 
 Sort of.  Frankly, there seems to have been very little hunger for
 unilateral client-side extension, and a very strong aversion from the
 server-side people to accepting the round-trip-any-XML requirement.
 

From this implementors point of view client-side extension simply is not
a requirement.

- James



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

2006-12-16 Thread James M Snell

The moral of the story is simple: clients need to know what they're
getting into.

1. Servers can accept or reject whatever they want.
2. it's really nice if servers let client's know up front what they
   intend to accept or reject
3. at this point there's no need for any kind of handshake protocol to
   determine what a server will accept or reject.  What's most likely
   to happen (and most likely to actually be used and work effectively)
   is that server's will put up websites [1] that document exactly how
   their endpoints work and what clients should expect.

- James

[1] http://code.google.com/apis/gdata/

Antone Roundy wrote:
 
 I'm not subscribed to the APP mailing list, so hopefully this isn't all
 redundant:
 
 On 12/15/06, Lisa Dusseault [EMAIL PROTECTED] wrote:
 A model where servers aren't required to keep such information won't, in
 practice, allow that kind of extension. If clients can't rely on their
 markup getting stored, then clients can't extend Atom unilaterally
 using XML
 markup.
 
 There are two different issues here, which I think has been mentioned,
 but which might bear being clearly stated:
 
 1) Do servers have to keep all extension data?
 
 2) Can a server accept an entry while discarding some or all extension
 data, or do they have to reject the entry and return an error code?
 
 I think the answer to the first question is clearly no--servers
 shouldn't be required to store all arbitrary data that is sent to them. 
 So the questions are:
 
 1) Which hurts more--data loss or rejected entries?
 
 2) Is there any way to reduce that pain?
 
 The pain of data loss is obvious--the data is lost.  The pain of
 rejected entries is having to fix and repost them or decide not to try
 again.
 
 In either case, it might be useful to be able to query the server
 somehow to find out what it will and won't preserve.  If data is
 discarded, you can figure that out after the fact by loading the
 resulting entry and checking whether the data is all there, but one
 might prefer to know ahead of time if something is going to be lost in
 order to be able to decide whether to post it or not.  If the entry is
 just going to be rejected, unless there's a way for the server to
 communicate exactly which data it had issues with, fixing the data to
 make it acceptable could be extremely difficult (Hmm, I'll leave this
 data out and try again...nope, still rejected. I'll put that back in and
 leave this out...nope. I'll take both out...nope. I'll put both back in
 and take yet another piece of data out...).
 
 So, how might a client query a server to see what it will preserve?  A
 few possibilities:
 
 1) Have some way to request some sort of description of what will and
 won't be preserved and what might be altered.  I don't know how one
 would go about responding to such an inquiry except to basically send
 back a list of what will be preserved, including some way to say I'll
 preserve unknown attributes here, I'll preserve unknown child elements
 (and their children) here, I'll store up to 32767 bytes here, etc. 
 If there is any known extension markup that a server wants to explicitly
 state that it won't preserve, there may need to be a way to do that too.
 
 2) Have a way to do a test post, where one posts the data one is
 considering posting (or something structurally identical), but says
 don't store this--just tell me what you WOULD store.  The response
 could include what would be returned if one were to load the data after
 it being stored, or it could be some sort of list of anything that would
 be discarded or altered.
 
 3) (I get the impression this could be done without requiring
 changes--is this the sort of process that has already been selected?) 
 Post the data as a draft, reload it to see if it's all still there.  If
 so, or if what has been preserved is acceptable, change it's status to
 published or whatever it's called.  If not delete it and give up or
 take whatever other action is appropriate.
 
 
 My impression is that data loss would be less painful and more easily
 dealt with than rejection of entries that won't be completely preserved.
 
 ...but I haven't followed the discussion, so what do I know.
 
 



Re: Inheritance of license grants by entries in a feed

2006-12-16 Thread James M Snell

Bob,

As always, thanks for the feedback.  These are excellent suggestions.
I'll work them into the next draft.

- James

Bob Wyman wrote:
 In general, I think the latest version of James Snell's license ID [1]
 is much better than earlier versions. I am particularly pleased that
 this draft only speaks of license grants. I remain, as always, opposed
 to anything that would encourage people to attempt to restrict the
 implied license to syndicate. I do, however, have a few small issues.
 The text on inheritance is, I think, almost correct in this draft
 however, as written it seems to create a risk of the incorrect granting
 of rights as well as unfortunate loss or decay of grants when entries
 are copied between feeds.
 
 The current draft states: (focus on the underlined bits. The first
 underlined sentence is too restrictive, the second too inclusive.)
 
 2.3. Inherited Licenses
 The license on a feed MAY be inherited by entries. Generally, a more
 specific license overrides the less specific license. More
 specifically, if an entry has any license link relations at all,
 including the undefined license, it does not inherit the license of
 the feed. If an entry has no license link relations, it does inherit
 the license of its parent feed(s). Since an entry may appear in
 multiple feeds, it may inherit multiple licenses. This is equivalent
 to stating multiple licenses on the entry itself.
 
 
 I am concerned that some readers who are not intimately familiar with
 RFC4287 may not understand that entries which contain atom:source
 elements do NOT inherit feed metadata from the feeds in which they are
 found. The text of the current draft seems to override this constraint
 on inheritance. Thus, I propose the following new wording for the third
 and fourth sentences in the first paragraph of section 2.3 (the one's
 quoted and underlined above):
 
 More specifically, if an entry has any license link relations at
 all, including the undefined license, [or, if the entry contains
 an atom:source element,] it does not inherit the license of the
 feed. If an entry has no license link relations[, and contains no
 atom:source element,] it does inherit the license of its parent feed(s).
 
 
 Additionally, I believe that this draft should align with the handling
 of atom:rights defined in section 4.2.11 of RFC4287 by adding the
 following text at some appropriate location:
 
 If an atom:entry which does not contain an atom:source is copied
 from one feed into another feed then if the feed into which it is
 copied contains a license, an atom:source element SHOULD be added to
 the copied entry. If a source feed contains a license, that license
 SHOULD be preserved in an atom:source element added to any entries
 copied from the source feed which do not already contain atom:source
 elements.
 
 
 The first constraint is necessary to ensure that the act of copying
 entries does not result in rights being granted by the copyist even
 though those rights were were not granted by the entry's author. The
 second constraint helps to prevent the loss or decay of rights as
 things are copied from feeds with licenses that grant rights into feeds
 that contain no or lesser grants.
 
 I realize that clarifying these constraints on inheritance allows for at
 least one odd result. That is, I might have a feed which contains
 entries whose atom:source elements declare license grants that differ
 greatly from what is seen in the feed's metadata even though all those
 entries claim the enclosing feed as their source. This actually makes
 a good bit more sense than it might seem to at first glance. The reason
 for this is that the rights granted for entries added to a feed can
 change over time even though changes to the feed's default rights may
 not impact previously created entries. Thus, a feed might have granted
 liberal rights when an entry was first created but might not offer the
 same grants when the entry was updated. The author should be able to
 maintain with the entry the rights that were originally granted (or not
 granted) rather than being forced to update the rights in order to do
 something as simple as a spelling correction. (Yes, I realize that the
 author could, in some cases, simply attach the old rights to the updated
 entry rather than using an atom:source which contains the same
 information. However, this can get messy in some situations and causes
 us to lose some information about the source of the license grants -- it
 may be useful in some cases to distinguish between licenses granted in
 feed metadata and those granted in entry metadata. Forcing attachment of
 licenses to entries would also require using the undefined license in
 more cases than is desirable.)
 
 I've got a few other comments -- destined for other messages.
 Nonetheless, this draft is looking much better than earlier drafts.
 
 bob wyman
 
 [1]
 

Re: License Draft: Tortured text re obligations...

2006-12-16 Thread James M Snell

+1. Another good edit.  I've started working on draft 11 with these edits.

- James

Bob Wyman wrote:
 There is, I think a bit of tortured text in James Snell's otherwise
 useful License ID[1].
 
 1.3. Terminology
 ...
 The term license refers to a potentially machine-readable
 description of explicit rights, and associated obligations, that
 have been granted to consumers of an Atom feed or entry.
 
 The problem is the underlined clause... One can't grant an obligation.
 (When you have a conjunction, you should be able to scan the sentence
 with only one element of the conjunction without losing meaning...) As
 written, the sentence can be read by nitpicking lawyers as: The term
 'license' refers to obligations that have been granted... Clearly, this
 isn't the intent. Thus, I propose the following rewording:
 
 The term license refers to a potentially machine-readable
 description of explicit rights that have been granted to consumers
 of an Atom feed or entry. Rights granted by a license may be
 associated with obligations which must be assumed by those
 exercising those rights.
 
 I realize that this is a bit more wordy than the existing text, however,
 I think it better perserves the author's intent. Also, it has the nice
 attribute of limiting the discussion of obligations to the scope of
 rights granted by the licenses -- not rights that might exist in the
 absence of the license. Nothing we do should encourage people to use
 in-feed or in-entry data to restrict rights which exist independent of
 an explicit license grant. Such rights may include fair-use rights, the
 right to create backups, the implied right to syndicate, etc. As with
 Creative Commons licenses, I believe our goal here should be to provide
 mechanisms to expand the rights granted -- not to restrict them.
 
  bob wyman
 
 [1]
 http://www.ietf.org/internet-drafts/draft-snell-atompub-feed-license-10.txt
 



Re: Atom Entry Documents

2006-12-15 Thread James M Snell

+1 many times over.

Lisa Dusseault wrote:
 I don't feel that changing parts of RFC4287 is appropriate for an
 individual draft, particularly when the WG that did RFC4287 exists. 
 Certainly in order to update RFC4287 it would *have* to be Proposed
 Standard.  What constitutes an update or change (rather than an optional
 extension) might be open to some debate.
 [snip]



Re: Atom Entry docs

2006-12-14 Thread James M Snell

I've found the arguments in favor of the type param to be more
convincing than those in favor of the new media type...

...so +1 to what Bob said.

- James

Tim Bray wrote:
 
 Bob Wyman wrote:
 There is, I think, a compromise position here which will avoid
 breaking those existing implementations which follow the existing RFC's.
 
 co-chair-modeIn case you haven't noticed, the WG is hopelessly split
 between the new-media-type option and the media-type-parameter option.
 If a few people were to put up their hands and say yeah what Bob said
 your co-chairs would probably do a hasty consensus grab./co-chair-mode
 
  -Tim
 

 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)

 Thus, APP would accept application/atom+xml when looking for a feed
 but might insist that entries be explicitly identified with a
 disambiguating type parameter. Thus, no code which currently uses
 application/atom+xml to designate a feed would be broken.
 Additionally, any code which is properly built and thus ignores
 unknown types will not be hurt when it sees
 application/atom+xml;type=entry since it will ignore the type
 parameter and dig around inside the data to figure out if it is feed
 or entry. The only code which will be hurt is some potential code that
 does not follow the existing RFCs for Atom or mime types. It is, I
 think, OK to occasionally break code that doesn't follow the specs.

 Whatever the technical arguments may be, I believe it is important
 from a political point of view that we do not change the definition
 of things defined in Atom. I am all for extending Atom, but not for
 changing Atom. We must not change the exiting specification unless
 there is some really serious harm being done. If we do, we risk losing
 the trust of at least some members of the community that we've built
 these last few years... Folk will remember that one of the
 advantages that is claimed for RSS is that it has been declared to
 be eternally free from modification. While I personally believe that
 that is silly, the proponents of RSS do have a point when they speak
 of the value of stable specs. If we allow the Atom spec to be
 *changed* so soon after it was accepted and we don't have a really,
 really good reason for doing it, we will simply have proven the often
 made claim that standards groups simply can't be trusted with
 important specifications. We will be encouraging more of the kind of
 standards making that resulted in the mess that is RSS...

 bob wyman

 PS: Since Kyle points out that GData, a Google product, is potentially
 impacted by the results of this discussion, I should state that I
 currently work for Google -- although I am not currently assigned to
 any product or project that has a direct interest in the definition of
 Atom, APP, etc... My participation in this discussion, at this time,
 is driven purely by personal interest.

 
 



Re: Atom Entry Documents

2006-12-14 Thread James M Snell

Quite a few folks seemed to have a preference to a separate doc.

- James

Asbjørn Ulsberg wrote:
 On Tue, 12 Dec 2006 08:39:25 +0100, James M Snell [EMAIL PROTECTED]
 wrote:
 
 Ideally, I would much rather this be a WG draft.  I pinged Tim about it
 the other day and he suggested that I go ahead with a I-D for now and
 that we can explore whether or not to move forward with it as a WG draft
 later.
 
 Can't just the APP specification include language that specifies a new
 MIME type for Atom Entries, since it's mostly APP implementations that
 have a use for it? Or would that be totally out of place?
 
 --Asbjørn Ulsberg -=|=-http://virtuelvis.com/quark/
 «He's a loathsome offensive brute, yet I can't look away»
 



Re: Atom Entry docs

2006-12-13 Thread James M Snell

Very helpful. Thank you.

- James

Martin Duerst wrote:
 At 13:14 06/12/13, James M Snell wrote:
 I think atom.entry and atom-entry are equally ugly; atom.entry would,
 however, appear to be more consistent with typical mime conventions.
 
 The dot is used for prefixes like vnd. (vendor) and so on.
 In the case of atom entries, atom-entry is more in line with
 the convention in other types.
 
 Regards,Martin.
 
 - James

 Tim Bray wrote:
 [snip]
 (James, did you really mean atom.entry with the ugly dot?)

  -Tim


 
 
 #-#-#  Martin J. Durst, Assoc. Professor, Aoyama Gakuin University
 #-#-#  http://www.sw.it.aoyama.ac.jp   mailto:[EMAIL PROTECTED] 
 
 



Re: Atom Entry docs

2006-12-13 Thread James M Snell



Sylvain Hellegouarch wrote:
 [snip]
 The GData server implementation requires a Content-Type value of
 application/atom+xml when POSTing or PUTting an Atom entry to a
 collection
 (for all non-media collections).   It will respond with a 400 (Bad Request)
 http error on any other content type.   It will also do the same if the
 request body contains an Atom feed document and not an Atom entry document.
 
 Right and I find that abusive of the mime type already. An UA that
 respects RFC 4287 and sends a feed to a collection that would state it
 accepts such media-type would not understand why it gets a 400 Bad
 Request (it's fairly interesting to point actually that because of that
 umbrella mime type you could not use the proper 415).
 

Which is precisely why acceptentry/accept exists.  Existing
implementations already have to basically ignore the content-type and
sniff the content.  Implementations will have to continue to do so with
the optional type param because it's optional.

- James



Re: Atom Entry Documents

2006-12-12 Thread James M Snell

*If* the document proceeds to Proposed Standard, the new RFC would
update RFC4287 either by adding a new type param or by deprecating the
use of application/atom+xml for atom entry documents in favor of a new
media type.  No other part of RFC4287 would be affected.

Ideally, I would much rather this be a WG draft.  I pinged Tim about it
the other day and he suggested that I go ahead with a I-D for now and
that we can explore whether or not to move forward with it as a WG draft
later.

- James

Mark Nottingham wrote:
 What would the relationship of that document be to RFC4287?
 
 Cheers,
 
 
 On 2006/12/11, at 7:32 PM, James M Snell wrote:
 
 The I-D would be an individual draft, not a WG draft.
 
 
 -- 
 Mark Nottingham http://www.mnot.net/
 
 



Re: Atom Entry docs

2006-12-12 Thread James M Snell

I think atom.entry and atom-entry are equally ugly; atom.entry would,
however, appear to be more consistent with typical mime conventions.

- James

Tim Bray wrote:
 
 [snip]
 (James, did you really mean atom.entry with the ugly dot?)
 
  -Tim
 
 



Re: Atom Entry Documents

2006-12-11 Thread James M Snell

Mark Baker wrote:
 On 12/10/06, James M Snell [EMAIL PROTECTED] wrote:
 Ok, the recent discussion seems to point towards a consensus towards
 distinctly flagging Entry Documents in the media type.
 
 Erm, isn't it up to the chairs to declare concensus?
 

The I-D would be an individual draft, not a WG draft.  The chairs only
decide consensus on WG stuff.  Once I get the initial version of the
draft up, we can see if it makes sense to move it forward as a WG draft,
in which case, I'll gladly let the chairs handle it.  :-)


 AFAICT, the discussion I was involved in failed to achieve it.  If I'm
 mistaken, I'll be happy to put in my 2c on a solution of course.
 

I think there was consensus that some form of mechanism for identifying
entry documents would be helpful.  Where I see a lack of consensus is on
the specific mechanism to use.

- James



Re: Atom Entry Documents

2006-12-11 Thread James M Snell

Sure you can.

Adding this to mime.types...

  application/atom+xmlatom
  application/atom+xml;type=entry entry
  application/atom+xml;type=feed  feed

works just fine in apache2.  Ask for a static file *.atom, and you get
application/atom+xml.  Ask for a static file *.entry and you get
application/atom+xml;type=entry.

- James

Hugh Winkler wrote:

   application/atom.entry+xml


 
 Another reason for +1 for B: consider serving static files, some of
 type entry, some of type feed. You can give each file type a different
 extension (.atom, .atom-entry) and configure Apache to serve the
 correct mime type for each. You could not configure Apache to serve
 files with the right type parameter, if you choose A.
 



Re: Fwd: PaceEntryMediatype

2006-12-08 Thread James M Snell

I'm fine with the type parameter approach so long as it is effective.
By effective I mean: Will existing implementations actually take the
time to update their behavior to properly handle the optional type
parameter.

- James

Bob Wyman wrote:
[snip]
  James suggests: the type parameter is [a] potentially more elegant
 solution. Elegance is goodness. Let's insist on elegant solutions in
 the absence of compelling reasons to be inelegant.
 
 bob wyman



Re: Fwd: PaceEntryMediatype

2006-12-08 Thread James M Snell



Bob Wyman wrote:
[snip]
 What you seem to be implying is that the majority of applications
 that process Atom Feed documents are not, in fact, supporting extremely
 important parts of the atom specification. I believe that any properly
[snip]

Not quite.  What I'm implying is that not all applications have the need
to implement the entire specification.  Atom Entry Documents and Atom
Feed Documents are each very useful but for different reasons.

 constructed Atom Feed parser will contain all the code needed to parse
 the most complex Atom Entry document. And, an entry document with an
 atom:source is semantically equivelant to an atom:feed with a single
 entry...  The problem here is that people insist on building Atom
 parsers that aren't capable of handling more semantics than legacy RSS.
 What we should be doing is encouraging people to exploit Atom and use
 its features -- atom:source among others -- that aren't supported by RSS.

+1 on all points.

  For a parser that properly handles the case of an atom:entry
 appearing within atom:feed, it should be trivially simple code to
 recognize  and handle an entry without a feed wrapper. I think there are
 even cases where this makes sense -- and you would even want to
 subscribe to such a thing:

Trivial, yes.  That's not really the issue for me.

[snip]
 In any case, while it appears reasonable (and sometimes efficient)
 for people to subscribe to Entry documents, I don't think we should do
 anything disruptive unless someone can establish actual harm being
 caused by the current state of affairs.
 

The fact that I cannot link to an Atom Entry Document from a browser
without it trying (and failing) to process it as a Feed Document is harmful.

- James



Re: PaceEntryMediatype

2006-12-07 Thread James M Snell

Content types are only useful when they help to differentiate how a
document is to processed.  If it was all about the format we could have
just used application/xml all along.  IMHO, There is already sufficient
evidence that entry documents and feed documents are processed
differently and thus deserve different content types.

- James

Henry Story wrote:
 
 Just to say that I strongly agree with Jan's points below. We should
 work to use the link relation type properly, and not get dazzled by the
 current misuse of the alternate relation.
 
 I have been wondering if there would not be a case for different mime
 types if one wanted to place a number of representations at the same url.
 
 One could for example have the following at the same place:
 
 - an html version of a blog post
 - an entry representation of that blog post
 - a feed for the history of changes to that blog post
 
 That would suggest having different media types because one could not
 place them at the same location if one only has application/atom+xml .
 That does not decide the issue as to whether it is a good idea to do so.
 
 For the moment I find the application/atom+xml;type=entry
 application/atom+xml;type=feed more appealing than the other new media
 types by the way.
 
 On the other hand having different mime types for every document format
 is also crazy. If someone invents a doc to describe cats, and someone
 else a doc to describe mice, are they going to need a new mime type? And
 what about a doc to describe policemen, and a doc to describe people? We
 could end up quickly with an infinite number of mime types which clearly
 would not help interoperability.
 
 Henry
 
 
 On 6 Dec 2006, at 23:22, Jan Algermissen wrote:
 On Dec 7, 2006, at 7:43 AM, A. Pagaltzis wrote:


 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?


 I am pretty sure it wasn't added for being able to tell people: Look,
 at the other end of this link is a feed.

 Seriously: how many feed readers are out there that base the decision
 wheter something is subscribeable on the type attribute of a link
 rather then on the link type?

 As an analogy: HTML browsers look for stylesheets where it says

link rel=stylesheet type=text/css href=/style.css /

 and not

link rel=alternate type=text/css href=/style.css /

 Eh?

 Jan
 
 
 
 
 On 6 Dec 2006, at 11:42, Jan Algermissen wrote:
 On Wednesday, December 06, 2006, at 08:30PM, Antone Roundy
 [EMAIL PROTECTED] wrote:

 On Dec 6, 2006, at 12:14 PM, Jan Algermissen wrote:

  I'd say: stick with the one media type that is currently there -
 there is no problem, just misconception about what it means to
 subscribe.

 A few reasons why a user agent might want to be able to tell the
 difference between a link to a feed and a link to an entry beforehand
 is in order to:

 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.
 
 I completely agree.
 
 
 On 6 Dec 2006, at 14:26, Jan Algermissen wrote:
 To make that decision, the agent has to look at the representation and
 the it is insignificant overhead to see if the thing returnes feed
 or entry.


 Not if the resource needn't be GET in the first place. If the whole
 operation can be decided upon the Content-Type returned in a HEAD
 request, or


 Ok, HEAD would save the extra payload, butI still think the reason
 for subscribing is NOT how the representation at the other end looks,
 it is based on the link semantics.
 
 



Re: PaceEntryMediatype

2006-12-06 Thread James M Snell

Actually, for the form application/atom+xml;type=entry it's more
likely that browsers will completely ignore the type param as they do
currently.

- James

fantasai wrote:
 [snip]
 That means rel=feed won't be implied on an Atom Entry document whether
 the
 new MIME type syntax is chosen to be
   application/atom.entry+xml
 or
   application/atom+xml;type=entry
 
 It also won't be implied on an Atom feed document if the syntax
   application/atom+xml;type=feed
 or
   application/atom+xml;type=archive
 is used, as was suggested earlier. This gives us a way to say
   link rel=alternate href=[..] type=[atom]
 without implying
   link rel=alternate feed href=[..] type=[atom]
 and without dropping the 'type' attribute entirely (which was the other
 solution pointed out on the whatwg list).
 
 ~fantasai
 
 



Re: PaceEntryMediatype

2006-12-06 Thread James M Snell

The key problem I have with the ;type=param is that it's optional and
likely to be ignored by a good number of implementations (which ends up
buying us nothing in terms of interop).  A separate media type is less
ideal but has greater practical value in that it addresses the problem
immediately.

- James

Andreas Sewe wrote:
 James M Snell wrote:
 Actually, for the form application/atom+xml;type=entry it's more
 likely that browsers will completely ignore the type param as they do
 currently.
 
 Well, if a browser ignores a media type's parameters, it will have to
 face the consequences: In the case of application/atom+xml;type=entry
 it would get application/atom+xml which means 'either an Atom Feed or
 Entry Document'; if it cannot handle Atom Entry Documents without
 breaking, it does not properly implement RFC 4287. But your point that
 *current* browsers silent discard a type parameter on
 application/atom+xml is moot anyway since the *current* Atom RFC
 specifies no such parameter.
 
 That being said, an *optional* type parameter offers the cleanest
 solution to distinguishing between the following three cases:
 
   1) Either an Atom Feed or Entry Document
   2) An Atom Feed Document
   3) An Atom Entry Document
 
 If RFC 4287 had defined separate media types for the latter two cases,
 we wouldn't have this problem, of course: Accept:
 application/atomfeed+xml, application/atomentry+xml would cover the
 first case just fine.
 
 But since the RFC sadly doesn't I am extremely reluctant to either
 deprecating the use of application/atom+xml for Atom Entry Documents
 or to introducing three media types overall when an optional parameter
 suffices.
 
 So, James, what is wrong with application/atom+xml;type=[entry|feed]?
 (A slim majority on this list seems to prefer it over defining separate
 media types.)
 
 Regards,
 
 Andreas Sewe
 
 



Re: PaceEntryMediatype

2006-12-06 Thread James M Snell


Andreas Sewe wrote:
 [snip]
 Applications which adhere to RFC 4287 and accept both Feed and Entry
 Documents labeled as application/atom+xml won't recognize
 application/atomentry+xml; they will have to be updated.
 

In consider that a feature.

- James



Re: PaceEntryMediatype

2006-12-06 Thread James M Snell



Jan Algermissen wrote:
 [snip]
 So they should be fixed, should they not? They seem to only have
 implemented half a media type.
 

The half they're interested in.  Why aren't they interested in the other
half?

- James



Re: PaceEntryMediatype

2006-12-06 Thread James M Snell

I certainly hope you're kidding about dropping entry docs.  Let's just
label 'em differently and move on.

- James

Jan Algermissen wrote:
 
 On Dec 6, 2006, at 11:30 PM, James M Snell wrote:
 


 Jan Algermissen wrote:
 [snip]
 So they should be fixed, should they not? They seem to only have
 implemented half a media type.


 The half they're interested in.  Why aren't they interested in the other
 half?
 
 
 Ha! Forget about the media type - let's drop entry documents.
 
 Jan
 

 - James
 
 



Re: feeds: what does atom:id denote?

2006-12-06 Thread James M Snell

Depends... is the client expected to process each discreet set of
entries as part of a single logical set or is each discreet set expected
to be processed as it's own complete set?  The former would be
equivalent to the way most feed readers work today.  The latter would be
equivalent to subscribing to a new feed each time.  In the former, each
feed should have the same atom:id; in the latter, each feed should have
a unique atom:id.

- James

Bill de hOra wrote:
 
 Hi,
 
 I'm sending entries over XMPP packaged up as feeds. A question that has
 come up - should the feed's atom:id change each time a feed is sent, or
 should it remain the same for all feeds issued from a client?
 
 cheers
 Bill
 
 



Atom Bidi Update

2006-12-06 Thread James M Snell

FYI,

I've posted an update to the proposed Atom bidi spec.

  http://www.ietf.org/internet-drafts/draft-snell-atompub-bidi-02.txt

Refresher: this adds a dir attribute to Atom Common Attributes that is
used to specify the base direction of text in Atom documents.

Changes: this draft has two significant changes.

 1. It drops the rlo and lro values.

 2. It specifies that UA's MAY right-align RTL text using the same
rules defined for HTML.

- James



Re: PaceEntryMediatype

2006-12-05 Thread James M Snell

When I process this entry,

http://www.google.com/calendar/feeds/jasnell%40gmail.com/public/basic/10ge5k2k7c488algfbau5q9qc0

What is the implied feed?  Where do I get the implied feeds metadata?
Title? ID? Anything?  If the entry contained an atom:source element you
might be able to assume that a logical feed is implied but absent any
other evidence, this is a standalone entry document that can be
processed without any assumption that a feed exists.

- James

Mark Baker wrote:
 On 12/4/06, James M Snell [EMAIL PROTECTED] wrote:
 All I can go on is evidence of how folks are actually using 'em... and
 they ain't using 'em as aliases. :-)
 
 Ok, I'll take empirical evidence too 8-)  Point the way ...
 
 Mark.
 



Re: PaceEntryMediatype

2006-12-05 Thread James M Snell

Indeed.  The application was written to expect a feed because of the
content-type but gets an entry instead and blows up.

- James

Jan Algermissen wrote:
 
 On Dec 5, 2006, at 9:15 PM, James M Snell wrote:
 

 When I process this entry,

 http://www.google.com/calendar/feeds/jasnell%40gmail.com/public/basic/10ge5k2k7c488algfbau5q9qc0

 
 Funny, Safari switches to feed://www.google.com :-)
 
 And then says it cannot process the entity (presumably because it is an
 entry).
 
 Jan
 
 
 
 



Re: PaceEntryMediatype

2006-12-05 Thread James M Snell



Mark Baker wrote:
 [snip]
 Ok, but I don't see that this would necessitate a new media type.
 It's just an entry without a feed.  You'd use the same code path to
 process that entry whether it were found in an entry or feed document,
 right?
 

Not necessarily.  Sure, it might be the same parser code, but not
necessarily the same bit of code using the parser.  Look at the way
Firefox, IE7, Bloglines, Liferea, etc all handle (or don't handle) Entry
documents versus Feed documents.  The majority of applications that most
frequently handle Atom Feed Documents have no idea how to deal with Atom
Entry Documents and I would wager that most applications that understand
how to process Atom Entry Documents and Atom Feed Documents typically
don't fall into the same category as most feed readers.


- James



Re: PaceEntryMediatype

2006-12-05 Thread James M Snell



Mark Baker wrote:
 [snip]
 Isn't that just a case of people not implementing the whole spec
 though?  FWIW, if that practice is widespread, then I think the group
 should consider deprecating entry documents.  Minting a new media type
 won't help.
 

The interesting question is *why* haven't those applications implemented
support for Entry Documents.  My guess is that Entry documents aren't
particularly interesting to their use cases which is likely because they
serve a different purpose.

Entry documents serve an extremely useful purpose in the Atom Publishing
Protocol.  They serve a significantly less useful purpose for your
typical feed reader.  That doesn't make them worthy of deprecation; it
just means entry documents are different than feed documents.

 Or, are there applications which only process entry documents and not
 feed documents?
 

Wrong question.  APP clients process both entry documents and feed
documents but do so for entirely different reasons than feed readers.

- James



Re: PaceEntryMediatype

2006-12-05 Thread James M Snell


Eric Scheid wrote:
 [snip]
 If an agent found an entry document, should it assume that it's a feed with
 one entry (so far) and allocate resources accordingly (ie. allow for
 cardinality of n++)?
 

No. In particular, if an atom:source element is not included there is no
way of knowing anything about the implied feed; no atom:id, no
atom:updated, no atom:title, none of the minimal bits of information the
atom spec requires for a feed.  An implied feed would serve no purpose.

 If an agent found an entry document, and then later returned to find a feed
 containing multiple entries, would it consider that a problem?

That obviously depends on how the code was written.  If it's an APP
client that's expecting to edit an Atom entry then, yeah, it'll quite
likely be a problem.

Now reverse it.  If an agent (e.g. firefox) finds a feed document and
then later returned to find an entry, would it consider that a problem?

 
 Would an agent finding multiple atom:content elements inside the one entry
 consider that a problem (other than it being a spec violation)?
 
 Are XML processors optimised for the fact that any given attribute can only
 occur once per element, and not twice or more .. eg. foo attr=1 attr=2
 / ?
 

Ok, you lost me on these last two. I'm not sure what you're getting at.

- James



Re: PaceEntryMediatype

2006-12-04 Thread James M Snell

And therein lies the problem: entry documents are NOT aliases for
single-entry feeds.

- James

Mark Baker wrote:
 [snip]
 True, but if entry documents are more or less aliases for single-entry
 feeds, why would anybody need to negotiate for one or the other?  I
 suggest that would have to be pretty obscure use case. 8-)
 
 Mark.
 



Re: PaceEntryMediatype

2006-12-02 Thread James M Snell



Jan Algermissen wrote:
 [snip]
 Is there any other media type that covers more than one document type
 (root element in the case of XML, but could also be non-XML mime types)?
 

application/xml

 It would be interesting to see how those (if any) deal with the issue.
 An example would maybe be iCalendar, Ithink.
 

application/xhtml+xml
application/atom+xml
...

 
 Also: If feeds and entries get their own media types, then a feed
 (consisting essentially of a bunch of entry documents comes pretty close
 to a multipart/related message - which would make the very existence of
 the feed media type questionable.
 

-1.

 
 And another thought: HTML has in a sense also two processing models
 within a single mime type (normal body and frames) and does not have a
 substantial problem with that, does it?
 

Different issue.  Frames and body are both used by the same types of
clients for the same purpose (rendering a UI).  They just lead to
different results.

- James



Re: PaceEntryMediatype

2006-12-01 Thread James M Snell


Kyle Marvin wrote:
 [snip]
 I expect that if you associated a 'rel' value with links that point to
 application/atom+xml, whether it is expected to be a feed or an entry
 would probably be part of the 'rel' description and thus not ambiguous
 at all.   I think the discussion started because of the aforementioned
 issues with the HTML5 link semantics, which is what should probably be
 fixed.
 

Not necessarily.

Consider:

  link rel=alternate type=application/atom+xml href=feed.xml /
  link rel=alternate type=application/atom+xml href=archive.xml /
  link rel=alternate type=application/atom+xml href=entry.xml /

What is the purpose of using alternate links? What is a UA supposed to
do with 'em? Why did I as a content publisher choose to use the
alternate link relation? Are all of these links of equal value to all
UA's?  Are they all expected to be processed in the same basic way?
Should an archive feed be treated the same way as a subscription feed?

Consider this use case:

In IBM's Activities implementation, each of our Activity collections
are entries in a top level master collection.  Every Activity has
several representations: An Atom entry, An Atom feed, A RSS feed, A HTML
page, etc.  On the html page I want to be able to link to each of the
various representations as alternates.  I also want folks to be able to
subscribe to the Atom feed and allow the folks who are building
APP-enabled editing tools to autodiscover the edit uri of the entry.  I
don't want UIs to show a subscription link to the Atom entry representation.

What I want is something like this:

  link rel=alternate subscribe
type=application/atom+xml
href=feed.xml /
  link rel=alternate edit
type=application/atom.entry+xml
href=entry.xml /
  link rel=alternate subsribe
type=application/rss+xml
href=rss.xml /

Given these links I have all of the information I need:

  * There are three alternate representations: An Atom Entry, An Atom
Feed and an RSS Feed.
  * There are two links I can subscribe to: An Atom Feed and an RSS Feed
  * There is one edit link

Note that this clearly separates the purpose of the link (rel) from the
resource type.  I don't care what the value of the type attribute is, if
rel includes the keyword subscribe (or feed, doesn't matter) then I
know I can subscribe to that resource.  If the rel contains the keyword
alternate I know it's an alternate representation, no other semantics
are implied.  Each of the keywords in the rel attribute are completely
orthogonal to one another.

Note also that there is a clear separation between the Atom Feed and
Entry types.  These are different document types intended for different
audiences and deserve different media types.

- James



Re: PaceEntryMediatype

2006-12-01 Thread James M Snell

You're right that the differentiation in the content-type is of less
importance but without it there's no way for me to unambiguously
indicate that a resource has both an Atom Feed representation and an
Atom Entry representation.  The best I could do is say This things has
two Atom representations.  Keep in mind that I want to be able to
differentiate the types of alternate representations available without
having to look at any of the other rel keywords.

- James

Kyle Marvin wrote:
 [snip]
 I see the separation but I'm still missing a clear justifiication for
 it.  I don't see content-type as having anything to do with the
 audience.  It's about what media format you'd get back if you
 dereference the href and rel is about how you can interpret/interact
 with it.   I feel like the primary audience for content-type is likely
 to be used in selecting some type of parser when retrieving the
 resource.  Orthogonal to this, the rel value assigns some semantic
 meaning to the resource (what does the entry or feed describe) and might
 also specify what interaction model you might expect via the href (ex.
 edit implies APP edit semantics on an entry resource).
 
 Cheers!
 



Re: PaceEntryMediatype

2006-12-01 Thread James M Snell

I could but after the discussions this week I'm not sure its worth it.

Yes, everything can be done using different rel values; the content-type
thing is more just an annoyance than anything else. I'll just make sure
that I never link my Atom entry documents using alternate (even tho
that's what they are).

- James

Kyle Marvin wrote:
 [snip]
 Can you explain why you want this?   I'm not trying to be relentless I
 just want to make sure I'm not missing something important while pushing
 back.
 
 -- Kyle
 
 



Re: PaceEntryMediatype

2006-11-30 Thread James M Snell

Well, it's all XML parsing so in one sense the processing is the same.
The key difference arises in how the various documents are used.  In my
experience, Atom Entry Documents are nearly the exclusive territory of
APP Clients and push notification services (e.g. Atom over XMPP) while
Feeds generally provide for the redistribution and indexing of entries.
 When I parse an entry document, there is no implied feed.

- James

Mark Baker wrote:
 Interesting, thanks.  But serving different purposes doesn't
 necessitate a new media type.  What's important is how the two types
 of documents are interpreted.
 
 How does your processing of an entry document differ from the
 processing of a feed containing (only) that same entry?  If processing
 the entry is a subset of processing the feed, then you probably don't
 need a new media type.
 
 Mark.
 
 On 11/30/06, James M Snell [EMAIL PROTECTED] wrote:


 Mark Baker wrote:
  [snip]
  Yes, but more than that.  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.
 

 Hmm.. I understand what you're saying but I don't think I agree.  In the
 APP implementations I've put together, Feed and Entry documents
 generally serve two entirely different purposes and are usually intended
 for two entirely different audiences.

 - James

 



Re: PaceEntryMediatype

2006-11-30 Thread James M Snell

The key problem with application/atom+xml;type=entry is that at least
one major browser (Firefox 2.0) still treats it as a feed and shows the
subscribe link. So while the type parameter is a potentially more
elegant solution, the new media type approach would likely be far less
disruptive.

- James

Antone Roundy wrote:
 [snip]
 Of the options presented, I'd favor adding a type parameter to
 application/atom+xml.  In addition to feed and entry, we may want
 archive.
 
 



Re: PaceEntryMediatype

2006-11-30 Thread James M Snell


Jan Algermissen wrote:
 [snip]
 Are there other problems you had in mind when writing the Pace?
 

Well, there are the issues that came up with regards to the APP accept
element; the issues regarding whether Atom Feeds can be posted to an APP
collection; the issue in the collection of collections use case where
it's not clear if content type=application/atom+xml src=foo /
points to an entry or a feed; I'm sure there are others that I'm not
thinking of right at the moment.  It seems that every couple of months
the issue of the media type duality comes up.

- James



Re: PaceEntryMediatype

2006-11-30 Thread James M Snell



Mark Baker wrote:
 [snip]
 If HTML 5 (and current practice) doesn't change, but we defer to them
 for the specification of autodiscovery, then a new media type would be
 one way forward.  But it should be reusable for all non-feed (i.e.
 from a user POV, as above) Atom documents, not just entry documents;
 perhaps application/atom-no-feed+xml.  It's an ugly hack, but it's
 better than the alternative of many more specific Atom-related media
 types, which atomentry+xml might set a precedent for.
 

Blech! :-)

I think it's worthwhile to separate the two distinct issues at play: The
Purpose of the Link and the Type of Resource.

The ambiguity in the media type has come up several times in WG
discussions for more than just autodiscovery.  Every time it comes up
there is some speculation about whether adding a type parameter would be
helpful then folks move on to something else without really coming to a
conclusion.

I agree with you that the HTML5 definition of alternate is lacking but
I understand why they've done things that way and I applaud their
effort.  They're documenting existing practice even if it is
fundamentally flawed.  At least they're moving things in the right
direction with the feed link relation but it's too early to tell if
that effort is going to pan out in the end.

 [snip]
 I prefer the new relationship to a new media type because it's less
 disruptive; it doesn't require futzing around with existing specs and
 implementations.
 

Possibly. But at this point I'm not yet convinced.

- James



Re: PaceEntryMediatype

2006-11-30 Thread James M Snell



Bill de hOra wrote:
 
 Well it's all octets so in one sense the processing is the same.
 [snip]

Btw, My apologies if my original comment about the xml parsing came
across as being snarky; that was not the intention.  The point I was
making was that how these things are processed depends entirely on how
you intend to use 'em.  So far I've seen no evidence that anyone intends
to use Entry Documents in the same way they use Feed Documents.

- James



Re: PaceEntryMediatype

2006-11-30 Thread James M Snell

Excellent summarization Antone, thank you.

Antone Roundy wrote:
 [snip]
 ? I haven't been following development of the APP, so forgive my
 ignorance, but can parameters be included in the accept element?
 

I'd have to double check the definition of media-range but the
original intent was that parameters would be allowed but likely rarely used.

 [snip]
 4) Create a new media type for entry documents, and add a parameter to
 application/atom+xml to differentiate between live and archive feeds
 (and for any other documents that have the identical format, but should
 be handled differently in significant cases).
 
 [snip]
 
 If we were starting from scratch, I'd probably vote for #1.  Since we're
 not, I'd vote for #4 first, and perhaps #5 second, but I'd have to think
 about #5 more first.
 

I personally don't care so much about differentiating archive feeds. At
this point I'm thinking that some combination of 4 and 5 would be best.

- James



Re: [rss-public] Autodiscovery IPR and Process Concerns

2006-11-30 Thread James M Snell

The AD was kind enough to point out that this statement is likely a bit
too vague.  The intended meaning was that I have no involvement in, or
awareness of, IPR that is in any way relevant to the atom work.  And, as
far as I am aware, there's nothing I am required to disclose.

- James

James M Snell wrote:
 [snip]
 There's absolutely nothing to disclose.
 [snip]



PaceEntryMediatype

2006-11-29 Thread James M Snell



http://www.intertwingly.net/wiki/pie/PaceEntryMediatype

#pragma section-numbers off

== Abstract ==

For the current Atom Publishing Protocol draft...

Create a new media type for Atom Entry Documents: application/atomentry+xml

Deprecate the use of application/atom+xml for Entry Documents.

== Status ==

Proposed

== Rationale ==

The fact that one media type is used for both Feed and Entry documents
has repeatedly come up as a problem on more than one occasion.  We have
an opportunity to fix this problem now.

== Proposal ==

Add to Section 6.1

{{{
Atom Entry Documents are identified with the application/atomentry+xml
media type (See section 15).
}}}

Renumber existing section 15.3 to 15.4

Insert..

{{{
15.3 Content-type registration for 'application/atomentry+xml'

   MIME media type name:  application
   MIME subtype name:  atomentry+xml
   Mandatory parameters:  None.
   Optional parameters:
  charset:  This parameter has semantics identical to the charset
 parameter of the application/xml media type as specified in
 [RFC3023].
   Encoding considerations:  Identical to those of application/xml as
  described in [RFC3023], Section 3.2.
   Security considerations:  As defined in this specification.
  In addition, as this media type uses the +xml convention, it
  shares the same security considerations as described in [RFC3023],
  Section 10.
   Interoperability considerations:  RFC 4287 registers the
  application/atom+xml Content-Type for both Atom Feed and Entry
  Documents.  For Atom Entry Documents, the use of the
  application/atom+xml type should be avoided.
   Published specification:  This specification.
   Applications that use this media type:  No known applications
  currently use this media type.

   Additional information:

   Magic number(s):  As specified for application/xml in [RFC3023],
  Section 3.2.
   File extension:  .atomentry
   Fragment identifiers:  As specified for application/xml in
  [RFC3023], Section 5.
   Base URI:  As specified in [RFC3023], Section 6.
   Macintosh File Type code:  TEXT
   Person and email address to contact for further information:
 This specification's author(s)
   Intended usage:  COMMON
   Author/Change controller:  IESG
}}}

== Impacts ==


== Notes ==



CategoryProposals



Re: PaceEntryMediatype

2006-11-29 Thread James M Snell

One such problem occurs in atom:link and atom:content elements.
Specifically:

  atom:link type=application/atom+xml href=a.xml /
  atom:content type=application/atom+xml src=b.xml /

Given no other information I have no way of knowing whether these are
references to Feed or Entry documents.

- James

Mark Baker wrote:
 -1
 
 - there's nothing special about an entry document
 - AFAICT (because they're not referenced from the pace), the problems
 referred to have other causes.  I prefer we fix those instead.
 
 Mark.
 



Re: PaceEntryMediatype

2006-11-29 Thread James M Snell

I'm fine either way. Wouldn't take that long for me to write up a draft.

- James

Tim Bray wrote:
 On Nov 29, 2006, at 8:16 AM, James M Snell wrote:
 
 http://www.intertwingly.net/wiki/pie/PaceEntryMediatype

 #pragma section-numbers off

 == Abstract ==

 For the current Atom Publishing Protocol draft...
 
 Irrespective of the merits of the new media type, the APP spec seems
 like the wrong place to define it.  Since nobody wants to obsolete 4287,
 why not a short clean standalone I-D?  -Tim
 
 



Re: [rss-public] Autodiscovery IPR and Process Concerns

2006-11-29 Thread James M Snell


Robert Sayre wrote:
 [snip]
 1.) IP Protections
 
 This is interesting for a couple of reasons. One is that Mr. Snell
 previously claimed that the document has nothing to do with my day
 job [1]. The second is the complete absurdity of worrying about IP
 protections on HTML tags that make an orange button appear.
 [snip]

Good grief.

What I said was that my volunteering to take over the editing of the
autodiscovery draft had nothing to do with my day job;  that is, no one
at IBM asked me to work on autodiscovery nor am I aware of anything at
IBM that is dependent on its completion.  The only reason I volunteered
to serve as editor was because it was a loose end that hadn't been tied
up yet by the WG.

 Do James Snell or IBM need to disclose any IP related to RSS and Atom
 autodiscovery?

There's absolutely nothing to disclose.  I just prefer to limit my
material contributions to various standards activities to organizations
whose IP policies have been vetted and approved by my employer's IP
lawyers or to posts on my personal weblog.  Your wiki qualifies as neither.

 2.) Structured Process
 
 Mr. Snell points at RFC2026. This is an individual draft. There is
 basically no consistent process. Anyone who claims otherwise is trying
 to deceive you. This group already has some good examples of the way
 RFC2026 is interpreted in practice. It would be very disingenuous to
 claim it constitutes structure.
 

I had originally suggested that the draft be resubmitted as a WG draft.
 The Area Director and the WG chairs suggested that since autodiscovery
was not covered under the original charter it would be better to pursue
it as an individual submission.  I decided to do so only on the
condition that the same open process used for the development of the
Atom and APP specs would be followed -- meaning that there would be no
closed door decisions and that clear consensus had to develop via open
discussions on the WG mailing list before any change to the document was
made.

 3.) Well, whatever. ;)
 
 a little confused,

Again, it would help if you quoted me accurately. My complete statement
can be found at [1].  All of the comments in my blog post were
specifically in regards to why I did not intend to participate in your
personal wiki documentation experiment. Good luck with it tho.

Now, to the WG as a whole: I really don't have any agenda for the
autodiscovery stuff other than to help foster it along.  If y'all think
there is a need for a I-D defining autodiscovery for Atom and APP, I've
got a few spare cycles to help with the editing.  If y'all think the
HTML5 stuff is sufficient, that's fine with me too.  If y'all want to go
some other direction with it, whatever.

- James

[1] http://www.snellspace.com/wp/?p=545



Re: PaceEntryMediatype

2006-11-29 Thread James M Snell



Mark Baker wrote:
 [snip]
 Yes, but more than that.  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.
 

Hmm.. I understand what you're saying but I don't think I agree.  In the
APP implementations I've put together, Feed and Entry documents
generally serve two entirely different purposes and are usually intended
for two entirely different audiences.

- James



Re: PaceEntryMediatype

2006-11-29 Thread James M Snell


John Panzer wrote:
 [snip]
  +1 to doing this outside of APP (but concerned about deprecating...)
 [snip]

An I-D / RFC can update another RFC without deprecating the entire
thing.  In this case the hypothetical new document would deprecate only
the use of the application/atom+xml media type for Atom Entry Documents.
 The rest of RFC 4287 would be unaffected.

- James



PaceMakeAutodiscoveryInformational

2006-11-28 Thread James M Snell

http://www.intertwingly.net/wiki/pie/PaceMakeAutodiscoveryInformational

#pragma section-numbers off

== Abstract ==

Move Autodiscovery forward as an Informational RFC

== Status ==

Proposed

== Rationale ==

At this point there seems to be very little reason for the autodiscovery
draft to be on the Standards Track.  An Informational RFC would appear
to be the most appropriate way forward.

== Proposal ==

Change the status of the autodiscovery draft to Informational.

== Impacts ==



== Notes ==




CategoryProposals



Restrict Rel and Type Values For Autodiscovery

2006-11-28 Thread James M Snell

http://www.intertwingly.net/wiki/pie/PaceRestrictRelValuesForAutodiscovery
http://www.intertwingly.net/wiki/pie/PaceRestrictTypeValuesForAutodiscovery

While I definitely understand the rationale behind this, it's unlikely
that the spec will actually lead to any change in behavior for the
various implementations.  Also, if memory serves correctly, media types
are inherently case-insensitive. We'd likely be better served to
document that as a best practice, the rel and type values should be
lower case but that many implementations will typically support upper
and mixed case values.

- James

p.s. I also note that the current HTML5 draft contains an editorial note
about needing to say something about the case sensitivity of attribute
values.



Re: PaceMakeAutodiscoveryInformational

2006-11-28 Thread James M Snell



Lachlan Hunt wrote:
[snip]
 Move Autodiscovery forward as an Informational RFC
 
 But if it were published as an informational RFC, what purpose would it
 serve?
 

To document best practice as it relates specifically to syndication
feeds.  For example, HTML5 says nothing about whether the relative order
of feed autodiscovery links within a document is significant.  The Atom
autodiscovery draft, however, defines that the order is significant.

 I intend to post a much more substantial review of the current draft
 shortly, but for now, see my comments on the RSS Autodiscovery spec,
 some of which will also apply to the Atom Autodiscovery spec.
 

Excellent. FWIW, I agree with just about all of your comments.

- James



Re: PaceMakeAutodiscoveryInformational

2006-11-28 Thread James M Snell

Robert Sayre wrote:
 [snip]
 To document best practice as it relates specifically to syndication
 feeds.

 The draft makes several requirements. That's not documenting best
 practice.
 [snip]

If the doc is changed to informative, the normative requirements in the
draft would need to be relaxed and/or refactored to describe current and
best practice.

I didn't write the doc so please don't complain to me about what's in
there.  If there is something that needs to be changed write up a pace.

- James



Re: PaceMakeAutodiscoveryInformational

2006-11-28 Thread James M Snell

I do believe that participation in this discussion is optional, as is
choosing whether or not to support any particular IETF draft
(informational or otherwise) so there is absolutely no need (or desire)
for you to waste your time here.  Your opinion that the document is
unnecessary has been noted.  Thanks for the input.

- James

Robert Sayre wrote:
 James M Snell wrote:
 I didn't write the doc so please don't complain to me about what's in
 there.  If there is something that needs to be changed write up a pace.
   
 
 Uh, no. I don't think you should write it at all, and I resent having to
 waste my time following this completely redundant effort to make sure it
 doesn't do damage by making requirements that would break backwards
 compatibility with previous Firefox versions.
 
 The WHAT-WG text is fine.
 
 - Rob
 



Re: PaceAutoDiscoveryDraftIsPointless

2006-11-28 Thread James M Snell

+0. I have no particular agenda on this other than helping to move it
forward if that's what folks want.  I will note, however, that the
overall response to PaceResurrectAutodiscovery was positive and there
seemed (to me at least) to be interest in at least discussing the future
of the draft. So please stop trying so hard to kill it before folks get
a chance to actually think it over and discuss it.  Your opinion counts
but it's not the only one that matters.

- James

Robert Sayre wrote:
 [snip]
 
 == Abstract ==
 
 Don't move forward with the autodiscovery draft.
 
 == Status ==
 
 Proposed
 
 == Rationale ==
 
 At this point there seems to be no reason for the autodiscovery draft to
 exist, since the WHAT-WG has ably covered the subject in Web
 Applications 1.0.
 
 http://whatwg.org/specs/web-apps/current-work/#alternate0
 
 Reasons given for the continued existence of the IETF draft have been
 non-technical doubletalk.
 
 == Proposal ==
 
 Stop work on the autodiscovery draft.
 
 == Impacts ==
 
 Reduces mailing list traffic and standards noise.
 



PaceRecommendFullURIsForAutodiscovery

2006-11-28 Thread James M Snell

http://www.intertwingly.net/wiki/pie/PaceRecommendFullURIsForAutodiscovery

Definite -1 on this one.  Buggy implementations just need to be fixed.
Writing specs to bugs is silly at best.

- James



Re: PaceMakeAutodiscoveryInformational

2006-11-28 Thread James M Snell

Ok, so given that I think this is the fifth or sixth note in which
you've said exactly the same thing, I think your position has been well
established.  What would be excellent is if you'd give others the
opportunity to weigh in on it before trying so hard to filibuster it.

- James

Robert Sayre wrote:
 Lachlan Hunt wrote:

 http://www.rssboard.org/news/70/vote-rss-autodiscovery-specification#discuss

 
 Like the Atom Autodiscovery draft, this spec serves no purpose.
 Autodiscovery is being defined in the HTML5 spec where it belongs, with
 both the alternate
 http://www.whatwg.org/specs/web-apps/current-work/#alternate0 and feed
 http://www.whatwg.org/specs/web-apps/current-work/#feed0 relationships.
 
 Fully agree.
 
 -Rob
 
 



Re: PaceAutoDiscoveryDraftIsPointless

2006-11-28 Thread James M Snell

Ted,

Please correct me if I get any of this incorrect, but for the sake of
the discussion I wanted to summarize the HTML5 [1][2] definitions here:

The following three links are equivalent to one another and specify that
the linked feed is an alternate representation of the page.

 link rel=alternate type=application/atom+xml href=... /
 link rel=alternate feed type=application/atom+xml href=... /
 link rel=feed alternate type=application/atom+xml href=... /

This means, for instance, if the links appear on a blog home page that
lists the 10 most recent entries, the feed will likely also be a listing
of the 10 most recent entries.  However, if the link appears on a page
that shows a single entry along with a listing of comments that have
been received, the link will likely point to an Atom feed listing that
entry and it's various comments.  Is that correct?

HTML 5 defines the feed relation as pointing to a feed that is not
necessarily an alternative representation of the page where it is found.
 This relation can, for instance, be used on a blog home page to point
to a comments feed or category feed.

 link rel=feed type=application/atom+xml href=... /

What I did not see in the HTML5 spec is any indication of whether the
order of link relations is significant.  I'm assuming that means that it
is not.  I'm also assuming that means that all alternate feed link
relations, with the same type attribute value, appearing anywhere within
the document are considered to be equivalent?

- James

[1] http://whatwg.org/specs/web-apps/current-work/#alternate0
[2] http://whatwg.org/specs/web-apps/current-work/#feed0

Edward O'Connor wrote:
 Robert Sayre wrote:
 Don't move forward with the autodiscovery draft.
 [...]
 At this point there seems to be no reason for the autodiscovery draft
 to exist, since the WHAT-WG has ably covered the subject in Web
 Applications 1.0.
 
 I am worried that there are three simultaneous efforts to spec out feed
 autodiscovery: WA1, the RSS board's recent spec, and this draft. Ideally
 this stuff would get specced just once. WHAT WG seems like a neutral
 ground, syndication-format wise, so perhaps they're best positioned to
 spec feed autodiscovery in a way that makes everybody happy.
 
 
 Ted
 



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

2006-11-28 Thread James M Snell

The problem I have with the WHAT-WG definition of the alternate and feed
relations is the unintended conflict that occurs when the alternate
representation of a page happens to be an Atom Entry Document.

The HTML5 draft says,

If the alternate keyword is used with the type attribute set to
the value application/rss+xml or the value application/atom+xml,
then the user agent must treat the link as it would if it had
the feed keyword specified as well.

It goes on to say,

The feed keyword indicates that the referenced document is a
syndication feed. If the alternate link type is also specified,
then the feed is specifically the feed for the current document

The problem with this is that the application/atom+xml media type is
also used for Atom Entry Documents:

  link rel=alternate type=application/atom+xml href=entry.xml /

The current WHAT-WG definition is inadequate.

There are three possible solutions:

  1. We ask the WHAT-WG to fix their spec so the ambiguity in the Atom
 media type is addressed

  2. We add a type parameter to the application/atom+xml media type
 to differentiate feed and entry documents,
 e.g. application/atom+xml;type=feed,
  application/atom+xml;type=entry

 When the media type is used without the type parameter,
 type=feed is assumed.

  3. We define a new media type for Atom Entry Documents,
 e.g. application/atomentry+xml

Given that there are significantly fewer instances of Atom Entry
Documents that would need to be updated and the fact that the ambiguity
in the Atom media type has come up as a problem before, I'd actually
lean strongly in favor of options 2 or 3.

- James

Henri Sivonen wrote:
 
 On Nov 28, 2006, at 22:11, Edward O'Connor wrote:
 
 WHAT WG seems like a neutral ground, syndication-format wise, so
 perhaps they're best positioned to spec feed autodiscovery in a way
 that makes everybody happy.
 
 +1 for leaving speccing this to the WHATWG.
 
 --Henri Sivonen
 [EMAIL PROTECTED]
 http://hsivonen.iki.fi/
 
 
 



Re: PaceAutoDiscoveryDraftIsPointless

2006-11-28 Thread James M Snell

Hello,

Over on the IETF Atom Syntax mailing list we're discussing whether or
not to pursue the autodiscovery draft that had previously been put on
the table [1] or to simply point to the HTML5 work and be done with it.
 While reviewing the HTML5 draft and comparing that to the Atom
auto-discovery draft, a couple of questions came to mind.

 1. Is the order of alternate link rels in a document significant?

 2. Are multiple alternate links with the same type attribute
considered to be equivalent regardless of where those links appear
in the document.

Thanks!

[1]
http://www.ietf.org/internet-drafts/draft-snell-atompub-autodiscovery-00.txt

- James

Edward O'Connor wrote:
 James,
 
 Please correct me if I get any of this incorrect, but for the sake of
 [...]
 What I did not see in the HTML5 spec is any indication of whether the
 order of link relations is significant. I'm assuming that means that
 it is not. I'm also assuming that means that all alternate feed link
 relations, with the same type attribute value, appearing anywhere
 within the document are considered to be equivalent?
 
 These are good questions, but you and I are equally able (or unable) to
 answer them. Perhaps they would be better asked to the WHAT WG community
 on their mailing list?
 
  http://whatwg.org/mailing-list
 
 
 Ted
 



Re: [whatwg] Alternate link clarifications [was Re: PaceAutoDiscoveryDraftIsPointless]

2006-11-28 Thread James M Snell



Ian Hickson wrote:
 [snip]
 Here, while the last three are also valid feeds, it is the first one that 
 should be considered the default when doing auto-discovery. This isn't to 
 say that the feed UA should ignore the other three, or that it should only 
 show them if the user goes out of his way to obtain them -- indeed, the 
 default relationship could be completely ignored. It just means that if 
 it has to automatically pick one, then the first one is the one it should 
 pick. (It might also decide to only pick the one that is both a feed and 
 an alternative representation of the document, instead of picking the 
 default feed.)
 

Hmm... Ok, I can live with that.

[snip]
 Assuming that A includes alternate links to B and C, Can I assume that B 
 is also an alternate of C; and vice versa?
 
 Oh, you mean is the 'alternative' link type transitive? I guess so. I've 
 added a paragraph to the spec stating this.
 

[EMAIL PROTECTED] I was trying to think of that word all afternoon.  Yes, I was
meaning to ask if they were transitive.


- James



[Fwd: I-D ACTION:draft-snell-atompub-autodiscovery-00.txt]

2006-11-27 Thread James M Snell
All:

With Phil Rignalda's permission, I have taken over the role of editor
for the Autodiscovery draft and at Lisa and Paul's suggestion I have
resubmitted the draft as an **individual** submission (as opposed to a
Working Group Draft).  Phil has requested that his name be removed from
the draft.

The process for moving forward on this spec will be the same as with
Atom and APP.  Change proposals will need to be submitted in the form of
Pace's on the wiki with a copy sent to atom-syntax.  Pace's need to
include spec ready text, when appropriate. When consensus emerges around
a particular pace, it will get incorporated into the draft.  Editorial
changes need not go through this process; just post a note to the
atom-syntax list and I'll make sure the change is made.

- James

 Original Message 
A New Internet-Draft is available from the on-line Internet-Drafts
directories.


Title   : Atom Feed Autodiscovery
Author(s)   : M. Pilgrim, J. Snell
Filename: draft-snell-atompub-autodiscovery-00.txt
Pages   : 14
Date: 2006-11-27

   This document specifies a machine-readable method of linking to an
   Atom feed from a HyperText Markup Language (HTML) or Extensible
   HyperText Markup Language (XHTML) document, using the link element.


A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-snell-atompub-autodiscovery-00.txt

To remove yourself from the I-D Announcement list, send a message to
[EMAIL PROTECTED] with the word unsubscribe in the body of
the message.
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce
to change your subscription settings.

Internet-Drafts are also available by anonymous FTP. Login with the
username anonymous and a password of your e-mail address. After
logging in, type cd internet-drafts and then
get draft-snell-atompub-autodiscovery-00.txt.

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
[EMAIL PROTECTED]
In the body type:
FILE /internet-drafts/draft-snell-atompub-autodiscovery-00.txt.

NOTE:   The mail server at ietf.org can return the document in
MIME-encoded form by using the mpack utility.  To use this
feature, insert the command ENCODING mime before the FILE
command.  To decode the response(s), you will need munpack or
a MIME-compliant mail reader.  Different MIME-compliant mail readers
exhibit different behavior, especially when dealing with
multipart MIME messages (i.e. documents which have been split
up into multiple messages), so check your local documentation on
how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

 Message/External-body; name="draft-snell-atompub-autodiscovery-00.txt": Unrecognized 
___
I-D-Announce mailing list
I-D-Announce@ietf.org
https://www1.ietf.org/mailman/listinfo/i-d-announce



Re: [Fwd: I-D ACTION:draft-snell-atompub-autodiscovery-00.txt]

2006-11-27 Thread James M Snell

Because I resubmitted the draft with no changes from its previous
version.  I intend to update references with the next iteration of the
draft.

- James

Tse Shing Chi (Franklin/Whale) wrote:
 Why is one of the normative references in draft 
 draft-ietf-atompub-format-11 instead of RFC4287?
 
 Franklin Tse
 [snip]



Re: feed id's and paged/archive feeds

2006-11-27 Thread James M Snell

Abdera has basic support for the extension elements and the paging links
(including prev-archive and next-archive).  It does not yet include an
implementation of the feed reconstruction algorithm but will shortly.
The implementation is part of the optional extensions module.

- James

Mark Nottingham wrote:
 Well, since you ask a leading question...
 
 I have a demo implementation of a client at:
  http://www.mnot.net/rss/history/
 and my blog does the server side:
  http://www.mnot.net/blog/index.atom
 
 James Holderness has mentioned an implementation, and the Apache abdera
 people seem to be planning something, based on their repository. I know
 of other folks who are planning to integrate into products and services,
 but I can't disclose anything more (I'd encourage them to, of course).
 Anybody else?
 
 The issue we're discussing here, though, isn't about ambiguities in
 *this* spec, but rather in Atom itself; i.e., what does a feed ID really
 identify?
 
 Cheers,
 [snip]



Re: [Fwd: I-D ACTION:draft-snell-atompub-autodiscovery-00.txt]

2006-11-27 Thread James M Snell


Robert Sayre wrote:
 James M Snell wrote:
 The process for moving forward on this spec will be the same as with
 Atom and APP.  
 
 No, it won't. It's not a WG document.
 

Ok, to be absolutely pedantic about it: the process will be as close as
possible to that used for Atom/APP with the obvious exception that it is
an individual submission and not a WG draft. Pace's to the wiki;
discussion on the mailing list; Consensus calls will be posted
periodically; I will be tallying the results; anyone can challenge if
they feel the need; the entire process will be done out in the open.

 Does the draft diverge from existing browser behavior? Do browsers
 implement aspects of the document differently? What problems have you
 seen that make standardization necessary?
 

I dunno... you're the one that that writes browser code, you tell me.

You certainly seemed to think it was a good fit before. In fact, on
January 19 of this year you posted [1]:

  I think the current draft reflects what implementations
   do pretty well

 Without some evidence that the document serves a purpose, I'm afraid I
 don't see the point.
 

You seemed to think it served a purpose last January [2].

The only changes that have been made to the document since your post
requesting that it be unexpired and finished is the expiration date and
the name of the editor.  Perhaps it's the latter change that has you
wondering whether this suddenly may not be worth standardizing?

[1] http://www.imc.org/atom-syntax/mail-archive/msg17716.html
[2] http://www.imc.org/atom-syntax/mail-archive/msg17713.html

 - Rob
 
 P.S. -- the author affiliation information in the draft appears to be
 inaccurate.
 

How so?  Given that my volunteering to serve as the editor of this
document has nothing to do with my day job it would be inappropriate and
dishonest for me to associate my employers name with the work.

- James



Re: Author element best practice

2006-11-27 Thread James M Snell

I personally just think it's way too early for us to really be able to
say much about it.  So far the APP implementations that have actually
been deployed seem to work rather consistently in that I can get a
single client (e.g. Abdera) to work with each with very little effort
and only minor variations (e.g. different auth schemes, some require
Content-Length on the post, others don't, some reject invalid entries,
others don't, etc).  Based on my experience thus far, I really don't
think it is going to be much of a problem.

- James

Asbjørn Ulsberg wrote:
 [snip]
 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?
 [snip]



Re: feed id's and paged/archive feeds

2006-11-26 Thread James M Snell

Mark Nottingham wrote:
 [snip]
 I think they do, although the draft is silent on it.
 [snip]

Good enough for me.

Also, the latest draft looks good to me. Ship it!

Thanks Mark.

- James



Re: Author element best practice

2006-11-26 Thread James M Snell

-1. The current spec is fine as is.  It currently does not say anything
about whether or not the post entry MUST be valid although that is,
indeed the spirit of the spec.  The spec does not say that servers MUST
reject entries that are not valid.  Servers are free to accept or reject
entries as they see fit.  No change is necessary.

- James

Sylvain Hellegouarch wrote:
 Tim Bray wrote:
 On Nov 22, 2006, at 3:11 AM, Sylvain Hellegouarch wrote:

 Say I POST an atom:entry to a collection URI, this entry does not have
 an atom:author
 If I were implementing the server, in this scenario I'd reject the post
 with an error message.  It's hard for me to see a scenario where the
 author info isn't already known and not providing it is still OK.  (In
 fact, it's hard for me to imagine a scenario in which the author info
 isn't already known, period.)  -Tim
 
 Right.
 If we stretch this idea a little then, 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 ?
 
 I think at least a MAY would give some weigh to implementors who wish to
 be really strict regarding the input the allow.
 
 - Sylvain
 
 



Re: autodiscovery draft vs namespaces

2006-11-26 Thread James M Snell

Kornel, thanks for the input. In the next rev of the draft (following
the initial reboot that should publish in a day or so) I'll see what I
can do to clarifying some of these issues.  As always, suggested spec
text is helpful and encouraged.  I will do my best to incorporate all
editorial changes.

- James

Kornel Lesinski wrote:
 
 
 I've noticed that draft-ietf-atompub-autodiscovery-01.txt doesn't
 mention XML namespaces and tag prefixes. XHTML can get even more complex
 than memo suggests:
 
 foo:link xmlns:foo=http://www.w3.org/1999/xhtml; rel=alternate
 type=application/atom+xml href=bar/foo:link
 
 My suggestion is that instead of specifying all quirks of X[HT]ML syntax:
 * require that XML parser is used for XHTML
 * if document turns out not to be well-formed (which often is the case
 with real-world XHTML), allow HTML parsing rules used as fallback
 
 And then simply state that in XHTML link element in
 http://www.w3.org/1999/xhtml; namespace should be used. An example
 XPath expression or W3C DOM-based pseudocode might be very helpful there.
 
 
 BTW: in all examples attributes have always the same order. They could
 be shuffled to emphasise that order is not significant.
 
 --regards, Kornel Lesiński
 
 



Re: The src attribute of atom:content

2006-11-19 Thread James M Snell

The spec can be changed, it's just not a great idea to do so until we
get a critical mass of issues that can't seem to be adequately worked
around.

You can accomplish what you're trying to do by throwing in an alternate
link, using the summary element and dropping the content.

entry
  titleExample Title/title
  idhttp://www.example.org//id
  summaryA simple explanation of quantum entaglement/summary
  link type=text/html src=http://www.example.org/; /
  published2006-11-19T13:05:00Z/published
  updated2006-11-19T13:05:00Z/updated
/entry

However, you should do as Aristotle suggests and file a bug report with
any aggregator that does not support the content/@src attribute.

- James


Tse Shing Chi (Franklin/Whale) wrote:
 Why can't change the specification? It is currently a proposed standard only.
 
 I still think that providing alternate content is very important... at 
 least... add an alt attribute to atom:content as if xhtml:img...
 
 Franklin
 
 -Original Message-
 From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of A. Pagaltzis
 Sent: Monday, November 20, 2006 00:15
 To: atom-syntax@imc.org
 Subject: Re: The src attribute of atom:content
 
 
 * 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,



Re: Forward Compatibility

2006-11-18 Thread James M Snell



Mark Nottingham wrote:
 [snip]
 ...new metadata can be added using extensions, rather than by versioning Atom.

It's also possible for new RFC's to update the current Atom namespace in
a backwards compatible way without deprecating/obsoleting RFC4287.

 However, XHTML 2.0 will have a new namespace
 http://www.w3.org/2002/06/xhtml2/;, and the chance of having more
 future versions of XHTML cannot be eliminated. Have Atom prepared for
 this?
 
 This was intentional; if we allowed future, non-backwards compatible
 versions of HTML to appear in the same places that XHTML1 content is
 allowed, processors wouldn't know what to do with it unless they
 understood XHTML2. Tying the allowed content to a specific version of
 XHTML promotes interoperability.
 

That said, Atom can currently carry XHTML2 by specifying the media type
and properly declaring the namespace.

- James



Re: Pseudo-Last Call on draft-nottingham-atompub-feed-history-07

2006-11-13 Thread James M Snell

There is the Feed Rank extension which can be used to specify the order
for entries but that's still a work in progress and has been a very low
priority for me.

IMHO, you should base this entirely on atom:id and atom:updated.  If you
find another entry with a duplicate atom:id and a newer atom:updated, it
takes precedence.  If you find an entry with a duplicate atom:id and an
older or equal atom:updated, the one you currently have takes
precedence.  If you want more granularity, look for app:edited elements.

- James

Mark Nottingham wrote:
 
 I haven't had any feedback on the possible change below. Does anyone
 want to see things move in this direction?
 
 Cheers,
 
 
 On 2006/10/11, at 10:06 PM, Mark Nottingham wrote:
 
 1. I think your document might need to address what's supposed to happen
 if duplicate items are discovered when trolling through the paged info.
 Newer replaces older? (That makes the most sense to me) Although I guess
 the argument might be, what's an 'item'?.

 I started going down that road in early drafts, but backed away from
 it when it started looking like a rat hole. :)

 To allow FH to normatively specify what to do with duplicates, you
 have to figure out the ordering of entries, so you can determine their
 relative precedence. Since Atom doesn't have any explicit ordering, FH
 would need to either assume ordering semantics implicitly, or doing
 something explicit in an extension.

 In the paged case, this seems like a tall order, because it's totally
 context-dependent; e.g., if you have OpenSearch or GData results, or
 orders for launching the missiles that are paged, and you happen to
 get a duplicate, the right thing to do may be very different.

 In the archived case, it's a little easier, because we're already
 inferring that the pages closes to current do have precedence, so we
 just need to figure out what to do about duplicates in the same feed
 document.

 I could see making the implied page-by-page precedence for Archived
 feeds in section 4 explicit. It would also be easy to add text saying
 that relative precedence in the same feed document can be determined
 by any extension that defines ordering, defaulting to the update time
 of the entries (or document order, topmost first? I think this is what
 most people do, but it seems contrary to the spirit of the Atom spec).
 I'm not crazy about actually defining an ordering extension (is one in
 progress? James?) in FH.
 
 
 -- 
 Mark Nottingham http://www.mnot.net/
 
 



Re: feed index

2006-11-06 Thread James M Snell

You can accomplish this using another Feed. e.g.,

feed
  ...
  entry
...
link type=application/atom+xml href=feed1.xml /
...
  /entry
  entry
...
link type=application/atom+xml href=feed2.xml /
...
  /entry
  ...
/feed

- James

Greger wrote:
 
 
 I'd like something that would define a set of feeds, rather than just a link
 to one single feed. 
 is there anywhere in the standard mentioned about feed indices( i.e.
 collection of feeds).??
 Ta
 --
 http://www.gregerhaga.net/
 http://hack-space.biz/
 There are no stupid questions, but there are stupid answers.
 
 



Re: [atom-syntax] Atom bidi

2006-11-03 Thread James M Snell

Robert,

It's been a few weeks since this came up.  I was wondering if you'd be
able to give some kind of estimate on when you might have a chance to
document what you had in mind for mozilla/firefox/thunderbird.  No
pressure, of course, I just don't want this issue to stall out for lack
of discussion.

- James

James M Snell wrote:
 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 whether to update the I-D and I'll hold off making any further
 updates to Abdera until after the WG makes a clear decision.
 
 - James
 
 James Holderness wrote:
 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 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 thing. (Except perhaps with this new XHTML
 Modularization madness, but that's best ignored.)

 



  1   2   3   4   5   6   >