Future of the Atom Features Draft

The Atom Features Draft has expired.  There was some
interest expressed
in having it moved forward but there was no solid consensus
formed
around the approach.  At this point, I don't really have the
time or
need to move it forward (the original need for which it was
developed
has evolved).  If anyone else feels that it is an important
thing to
move forward, I will gladly hand over the xml of the source
doc and will
offer input however I can.

- James

James,

will your evolved use case eventually lead to a public 
(draft) APP  
extension that overlaps with what the features draft
expresses?

Jan


On May 15, 2008, at 4:50 PM, James M Snell wrote:

>
> The Atom Features Draft has expired.  There was some
interest  
> expressed
> in having it moved forward but there was no solid
consensus formed
> around the approach.  At this point, I don't really
have the time or
> need to move it forward (the original need for which it
was developed
> has evolved).  If anyone else feels that it is an
important thing to
> move forward, I will gladly hand over the xml of the
source doc and  
> will
> offer input however I can.
>
> - James
>
>


--
Jan Algermissen
INTAKI . http://www.intaki.com/

Right now, no.  I'm basically punting the features stuff
completely. 
If/when something is standardized, I'll revisit.  I just no
longer have 
enough of an immediate need for it to justify the time and
effort to 
work on it myself.

- James

Jan Algermissen wrote:
> James,
> 
> will your evolved use case eventually lead to a public 
(draft) APP 
> extension that overlaps with what the features draft
expresses?
> 
> Jan
> 
> 
> On May 15, 2008, at 4:50 PM, James M Snell wrote:
> 
>>
>> The Atom Features Draft has expired.  There was
some interest expressed
>> in having it moved forward but there was no solid
consensus formed
>> around the approach.  At this point, I don't really
have the time or
>> need to move it forward (the original need for
which it was developed
>> has evolved).  If anyone else feels that it is an
important thing to
>> move forward, I will gladly hand over the xml of
the source doc and will
>> offer input however I can.
>>
>> - James
>>
>>
> 
> 
> -- 
> Jan Algermissen
> INTAKI . http://www.intaki.com/
> 
> 
> 
> 
> 
> 

At 10:50 AM 2008-05-15, James M Snell wrote:

>The Atom Features Draft has expired.  There was some
interest expressed
>in having it moved forward but there was no solid
consensus formed
>around the approach.  At this point, I don't really have
the time or
>need to move it forward (the original need for which it
was developed
>has evolved).

Can someone elaborate or point me to something to explain
the 
original need and what it has evolved to?

Paul

>  If anyone else feels that it is an important thing to
>move forward, I will gladly hand over the xml of the
source doc and will
>offer input however I can.
>
>- James
>
>
>

The core Atompub spec gives server implementations a broad
set of 
options to choose from.  For instance, a server can choose
to allow 
plain text title's in entries but not html or xhtml titles. 
A server 
could choose to accept multiple categories or just a single
category.  A 
server could choose to allow post-dated entries by allowing
the client 
to include a future atom:published date. A server could
choose to 
support any combination of extension elements or app:control
elements to 
achieve a wide variety of behaviors.  The list goes on.  The
original 
need for the features draft was to provide a mechanism for
servers to 
communicate implementation choices to a client so that the
client could 
do the right thing when interacting with the service.  The
main 
challenge is that we were never really able to get consensus
around the 
spec and I no longer have time to put much attention on it
because of 
other, higher priority projects.

- James

Paul Denning wrote:
> At 10:50 AM 2008-05-15, James M Snell wrote:
> 
>> The Atom Features Draft has expired.  There was
some interest expressed
>> in having it moved forward but there was no solid
consensus formed
>> around the approach.  At this point, I don't really
have the time or
>> need to move it forward (the original need for
which it was developed
>> has evolved).
> 
> Can someone elaborate or point me to something to
explain the original 
> need and what it has evolved to?
> 
> Paul
> 
>>  If anyone else feels that it is an important thing
to
>> move forward, I will gladly hand over the xml of
the source doc and will
>> offer input however I can.
>>
>> - James
>>
>>
>>
> 
> 
>