Re: Unofficial Last Call - draft-snell-atompub-feed-thread-04.txt

[James M Snell]

Hmm.. not too sure.  It's entirely possible, of course, but I'm not sure 
that's it's worthwhile.  The slash RSS 1.0 module already has an element 
that can be used for this 
(http://web.resource.org/rss/1.0/modules/slash/). 


Byrne Reese wrote:


Any chance this specification could be extended to contain meta data
about the replies? Specifically, how many replies that may exist for a
given entry?

I would love a mechanism to be able to recreate:

--- cut here ---
POST TITLE

Lorem ipsum dolor sit amet, consectetuer adipiscing elit. 
Donec sit amet nisl. Morbi pretium ultrices sapien. Mauris 
pretium ultrices odio. Duis mauris. Aliquam est. 


Posted by: Byrne on Dec 15, 2005   Comments (10)
--- cut here ---

Perhaps?



 


-Original Message-
From: [EMAIL PROTECTED] 
[mailto:[EMAIL PROTECTED] On Behalf Of James M Snell

Sent: Saturday, October 22, 2005 7:45 AM
To: James Holderness
Cc: Atom Syntax
Subject: Re: Unofficial Last Call - 
draft-snell-atompub-feed-thread-04.txt



Ah crap, that's what I get for editing multiple docs at once. 
It's supposed to be -01 and -02.  I'll get that fixed.  The 
-01 is the current version; the new version waiting to 
publish has no significant updates (just some minor typo 
stuff) so you should safely be able to base your feedback on 
the -01 version.


James Holderness wrote:

   

[1] draft-snell-atompub-feed-thread-03.txt (current version) [2] 
draft-snell-atompub-feed-thread-04.txt (new version waiting to 
publish... no significant changes)
   

Do you have a link for these? The only copy I could find on 
 

ietf.org 
   


was -01.


 

   



 

Re: Sponsored Links and other link extensions

[Eric Scheid]

On 26/10/05 4:18 AM, "Antone Roundy" <[EMAIL PROTECTED]> wrote:

> The only thing I would change is the name of x:mirror/@title to make
> it clear that it isn't intended(?) to replace the parent link's
> @title.  My current favorite name is "label".

+1

Re: How to represent an authenticated identity in an tag

[Tim Bray]

On Oct 25, 2005, at 5:02 PM, Byrne Reese wrote:


The above is accomodated by the current spec, but the following is
something we would also like to represent somehow in a standard way:

* their authenticated identity (e.g. "breese") and the authenticating
authority (e.g. "LiveJournal," "TypeKey," "OpenID," etc.)


Sounds like an obvious candidate for an exception; why don't you and  
one or two competitors sketch it out and do an I-D?  I'd sure be in  
favor.  -Tim

How to represent an authenticated identity in an tag

[Byrne Reese]

This is a topic that has come up recently in conversations here at Six
Apart that I thought I would share with a broader community to hear your
feedback and thoughts on the subject:

We see a value in representing the following attributes about an author:

* their Display Name (e.g. "Byrne Reese")
* their Email (why anyone would want to publish this an easily parsable
document eludes me, but that is not relevant :)
* their Web URL

The above is accomodated by the current spec, but the following is
something we would also like to represent somehow in a standard way:

* their authenticated identity (e.g. "breese") and the authenticating
authority (e.g. "LiveJournal," "TypeKey," "OpenID," etc.)

This is more important/relevant IMHO to publishing feeds for comments
(in fact I personally would not like to reveal my TypePad, MovableType,
etc username to the outside world for the posts I write), where I
believe knowing the authenticated entity is valuable.

Part of the value I see in supporting this to provide a mechanism for
determining whether a comment was an authenticated comment or not.

Of course, some may think that one's username is considered private and
priveleged information and should not be shared publicly.

Thoughts?

Byrne Reese
Manager, Platform Technology
http://www.sixapart.com/pronet/
 

RE: Sponsored Links and other link extensions

[Byrne Reese]

+1 to James' +1 of Eric's -1. 

> -Original Message-
> From: [EMAIL PROTECTED] 
> [mailto:[EMAIL PROTECTED] On Behalf Of James M Snell
> Sent: Monday, October 24, 2005 8:13 PM
> To: Eric Scheid
> Cc: Atom Syntax
> Subject: Re: Sponsored Links and other link extensions
> 
> 
> Eric Scheid wrote:
> 
> >On 25/10/05 5:48 AM, "A. Pagaltzis" <[EMAIL PROTECTED]> wrote:
> >
> >  
> >
> >> >>  rel="enclosure" type="audio/mpeg"
> >>  href="http://example.com/file.mp3";
> >>  encl:mirrors="http://www2.example.com/file.mp3
> >>http://www3.example.com/file.mp3";
> >>  xml:id="x-file"
> >>  />
> >> >>  rel="alternative-enclosure" type="application/ogg"
> >>  href="http://example2.com/file.ogg";
> >>  encl:alternative-to="x-file"
> >>  />
> >>
> >>
> >
> >-1 ... this is starting to get ugly.
> >
> >
> >e.
> >
> >
> >  
> >
> +1 to Eric's -1.  Let's keep it simple.
> 
> 
>
> 
> - James
> 
> 

RE: Unofficial Last Call - draft-snell-atompub-feed-thread-04.txt

[Byrne Reese]

Any chance this specification could be extended to contain meta data
about the replies? Specifically, how many replies that may exist for a
given entry?

I would love a mechanism to be able to recreate:

--- cut here ---
POST TITLE

Lorem ipsum dolor sit amet, consectetuer adipiscing elit. 
Donec sit amet nisl. Morbi pretium ultrices sapien. Mauris 
pretium ultrices odio. Duis mauris. Aliquam est. 

Posted by: Byrne on Dec 15, 2005   Comments (10)
--- cut here ---

Perhaps?



> -Original Message-
> From: [EMAIL PROTECTED] 
> [mailto:[EMAIL PROTECTED] On Behalf Of James M Snell
> Sent: Saturday, October 22, 2005 7:45 AM
> To: James Holderness
> Cc: Atom Syntax
> Subject: Re: Unofficial Last Call - 
> draft-snell-atompub-feed-thread-04.txt
> 
> 
> Ah crap, that's what I get for editing multiple docs at once. 
>  It's supposed to be -01 and -02.  I'll get that fixed.  The 
> -01 is the current version; the new version waiting to 
> publish has no significant updates (just some minor typo 
> stuff) so you should safely be able to base your feedback on 
> the -01 version.
> 
> James Holderness wrote:
> 
> >
> >> [1] draft-snell-atompub-feed-thread-03.txt (current version) [2] 
> >> draft-snell-atompub-feed-thread-04.txt (new version waiting to 
> >> publish... no significant changes)
> >
> >
> > Do you have a link for these? The only copy I could find on 
> ietf.org 
> > was -01.
> >
> >
> 
> 

Re: icon and logo on entry

[James M Snell]

Yep.. the only challenge with your example is that atom:link's should 
not contain atom:link's...


Henry Story wrote:

Oh I think I get it now. You want to specify the logo and icon of a  
resource

on the other side of a link.


So generalizing the suggestion:

   
   Atom-Powered Robots Run Amok
   
   
   http://example.org/2003/12/13/atom03";>
 http://example.org/2003/12/13/ 
atom03-large.jpeg"/>
 http://example.org/2003/12/13/ 
atom03-small.jpeg"/>

   
   urn:uuid:1225c695-cfb8-4ebb--80da344efa6a
   2003-12-13T18:30:02Z
   Some text.
   

Makes sense to me.


Henry
http://blogs.sun.com/roller/page/bblfish/

On 25 Oct 2005, at 22:23, Henry Story wrote:




On 25 Oct 2005, at 22:08, James M Snell wrote:




I've been wanting to do the same thing for link elements.



Nice :-)



Let's propose a single solution:


 {url}
 {url}
 
   {url}
   {url}
 




Is the above a single solution, or two solutions? I can't quite  tell 
the

difference.

Would they (it?) be equivalent to the following:


   Atom-Powered Robots Run Amok
   
   
   http://example.org/2003/12/13/atom03"/>
   urn:uuid:1225c695-cfb8-4ebb--80da344efa6a
   2003-12-13T18:30:02Z
   Some text.
 

I would think the media type is very much optional here.



Both elements should follow the exact same rules as the existing  
atom:logo and atom:icon elements.




Do you mean rules, or do you mean semantics? (ie: we just copy and  
paste the text

from the atom syntax doc, replacing feed with entry)



Henry




- James

Henry Story wrote:





I'd like to propose an extension that would allow something very  
much  like
icon and logo to be added to an entry, the way it currently is   
allowed on a feed.
I have been publishing entries like this for over a year now [1],  
and  so has
James Gosling [2], and other users of BlogEd. It would be really  
nice  to keep

this semantic information in the feed somehow.

Perhaps something like:

http://www.w3.org/2005/Atom";>

 Example Feed
 http://example.org/"/>
 2003-12-13T18:30:02Z
 
   John Doe
 
 urn:uuid:60a76c80-d399-11d9-b93C-0003939e0af6
 ./Image1-large.jpeg
 ./Image1-small.jpeg
 
   Atom-Powered Robots Run Amok
   ./Image5-large.jpeg
   ./Image5-small.jpeg
   http://example.org/2003/12/13/atom03"/>
   urn:uuid:1225c695-cfb8-4ebb--80da344efa6a
   2003-12-13T18:30:02Z
   Some text.
 


Though from what I have said in other posts about relative uris in
extension elements I suppose it would be better to have a new  link 
type.


Any ideas?

Henry

[1] http://bblfish.net/blog/
http://blogs.sun.com/roller/page/bblfish/
[2] http://blogs.sun.com/roller/page/jag/

Re: icon and logo on entry

[Henry Story]

Oh I think I get it now. You want to specify the logo and icon of a  
resource

on the other side of a link.


So generalizing the suggestion:

   
   Atom-Powered Robots Run Amok
   
   
   http://example.org/2003/12/13/atom03";>
 http://example.org/2003/12/13/ 
atom03-large.jpeg"/>
 http://example.org/2003/12/13/ 
atom03-small.jpeg"/>

   
   urn:uuid:1225c695-cfb8-4ebb--80da344efa6a
   2003-12-13T18:30:02Z
   Some text.
   

Makes sense to me.


Henry
http://blogs.sun.com/roller/page/bblfish/

On 25 Oct 2005, at 22:23, Henry Story wrote:




On 25 Oct 2005, at 22:08, James M Snell wrote:




I've been wanting to do the same thing for link elements.



Nice :-)



Let's propose a single solution:


 {url}
 {url}
 
   {url}
   {url}
 




Is the above a single solution, or two solutions? I can't quite  
tell the

difference.

Would they (it?) be equivalent to the following:


   Atom-Powered Robots Run Amok
   
   
   http://example.org/2003/12/13/atom03"/>
   urn:uuid:1225c695-cfb8-4ebb--80da344efa6a
   2003-12-13T18:30:02Z
   Some text.
 

I would think the media type is very much optional here.



Both elements should follow the exact same rules as the existing  
atom:logo and atom:icon elements.




Do you mean rules, or do you mean semantics? (ie: we just copy and  
paste the text

from the atom syntax doc, replacing feed with entry)



Henry




- James

Henry Story wrote:





I'd like to propose an extension that would allow something very  
much  like
icon and logo to be added to an entry, the way it currently is   
allowed on a feed.
I have been publishing entries like this for over a year now [1],  
and  so has
James Gosling [2], and other users of BlogEd. It would be really  
nice  to keep

this semantic information in the feed somehow.

Perhaps something like:

http://www.w3.org/2005/Atom";>

 Example Feed
 http://example.org/"/>
 2003-12-13T18:30:02Z
 
   John Doe
 
 urn:uuid:60a76c80-d399-11d9-b93C-0003939e0af6
 ./Image1-large.jpeg
 ./Image1-small.jpeg
 
   Atom-Powered Robots Run Amok
   ./Image5-large.jpeg
   ./Image5-small.jpeg
   http://example.org/2003/12/13/atom03"/>
   urn:uuid:1225c695-cfb8-4ebb--80da344efa6a
   2003-12-13T18:30:02Z
   Some text.
 


Though from what I have said in other posts about relative uris in
extension elements I suppose it would be better to have a new  
link type.


Any ideas?

Henry

[1] http://bblfish.net/blog/
http://blogs.sun.com/roller/page/bblfish/
[2] http://blogs.sun.com/roller/page/jag/

Re: icon and logo on entry

[Henry Story]

On 25 Oct 2005, at 22:08, James M Snell wrote:



I've been wanting to do the same thing for link elements.


Nice :-)


Let's propose a single solution:


 {url}
 {url}
 
   {url}
   {url}
 



Is the above a single solution, or two solutions? I can't quite tell the
difference.

Would they (it?) be equivalent to the following:


   Atom-Powered Robots Run Amok
   
   
   http://example.org/2003/12/13/atom03"/>
   urn:uuid:1225c695-cfb8-4ebb--80da344efa6a
   2003-12-13T18:30:02Z
   Some text.
 

I would think the media type is very much optional here.


Both elements should follow the exact same rules as the existing  
atom:logo and atom:icon elements.


Do you mean rules, or do you mean semantics? (ie: we just copy and  
paste the text

from the atom syntax doc, replacing feed with entry)



Henry



- James

Henry Story wrote:




I'd like to propose an extension that would allow something very  
much  like
icon and logo to be added to an entry, the way it currently is   
allowed on a feed.
I have been publishing entries like this for over a year now [1],  
and  so has
James Gosling [2], and other users of BlogEd. It would be really  
nice  to keep

this semantic information in the feed somehow.

Perhaps something like:

http://www.w3.org/2005/Atom";>

 Example Feed
 http://example.org/"/>
 2003-12-13T18:30:02Z
 
   John Doe
 
 urn:uuid:60a76c80-d399-11d9-b93C-0003939e0af6
 ./Image1-large.jpeg
 ./Image1-small.jpeg
 
   Atom-Powered Robots Run Amok
   ./Image5-large.jpeg
   ./Image5-small.jpeg
   http://example.org/2003/12/13/atom03"/>
   urn:uuid:1225c695-cfb8-4ebb--80da344efa6a
   2003-12-13T18:30:02Z
   Some text.
 


Though from what I have said in other posts about relative uris in
extension elements I suppose it would be better to have a new link  
type.


Any ideas?

Henry

[1] http://bblfish.net/blog/
http://blogs.sun.com/roller/page/bblfish/
[2] http://blogs.sun.com/roller/page/jag/

Re: icon and logo on entry

[James M Snell]

I've been wanting to do the same thing for link elements.  Let's propose 
a single solution:



 {url}
 {url}
 
   {url}
   {url}
 


Both elements should follow the exact same rules as the existing 
atom:logo and atom:icon elements.


- James

Henry Story wrote:



I'd like to propose an extension that would allow something very much  
like
icon and logo to be added to an entry, the way it currently is  
allowed on a feed.
I have been publishing entries like this for over a year now [1], and  
so has
James Gosling [2], and other users of BlogEd. It would be really nice  
to keep

this semantic information in the feed somehow.

Perhaps something like:

http://www.w3.org/2005/Atom";>

 Example Feed
 http://example.org/"/>
 2003-12-13T18:30:02Z
 
   John Doe
 
 urn:uuid:60a76c80-d399-11d9-b93C-0003939e0af6
 ./Image1-large.jpeg
 ./Image1-small.jpeg
 
   Atom-Powered Robots Run Amok
   ./Image5-large.jpeg
   ./Image5-small.jpeg
   http://example.org/2003/12/13/atom03"/>
   urn:uuid:1225c695-cfb8-4ebb--80da344efa6a
   2003-12-13T18:30:02Z
   Some text.
 


Though from what I have said in other posts about relative uris in
extension elements I suppose it would be better to have a new link type.

Any ideas?

Henry

[1] http://bblfish.net/blog/
http://blogs.sun.com/roller/page/bblfish/
[2] http://blogs.sun.com/roller/page/jag/

icon and logo on entry

[Henry Story]

I'd like to propose an extension that would allow something very much  
like
icon and logo to be added to an entry, the way it currently is  
allowed on a feed.
I have been publishing entries like this for over a year now [1], and  
so has
James Gosling [2], and other users of BlogEd. It would be really nice  
to keep

this semantic information in the feed somehow.

Perhaps something like:

http://www.w3.org/2005/Atom";>

 Example Feed
 http://example.org/"/>
 2003-12-13T18:30:02Z
 
   John Doe
 
 urn:uuid:60a76c80-d399-11d9-b93C-0003939e0af6
 ./Image1-large.jpeg
 ./Image1-small.jpeg
 
   Atom-Powered Robots Run Amok
   ./Image5-large.jpeg
   ./Image5-small.jpeg
   http://example.org/2003/12/13/atom03"/>
   urn:uuid:1225c695-cfb8-4ebb--80da344efa6a
   2003-12-13T18:30:02Z
   Some text.
 


Though from what I have said in other posts about relative uris in
extension elements I suppose it would be better to have a new link type.

Any ideas?

Henry

[1] http://bblfish.net/blog/
http://blogs.sun.com/roller/page/bblfish/
[2] http://blogs.sun.com/roller/page/jag/

Re: Sponsored Links and other link extensions

[Antone Roundy]

On Oct 25, 2005, at 1:16 PM, James M Snell wrote:
Also, assuming the title on the main link is supposed to describe  
the download file itself, there appears to be no way to inform the  
user of the mirror location of the main URI. Without a location  
name of some sort, the user can't make an informed decision about  
which mirror would be best to use. Perhaps something along the  
line of Antone's "label" suggestion might help here.




I could just do this:

http://example.com/ 
softwarepackage.tar.gz" type="application/x-gzip" x:group="software- 
package" nf:follow="no" >
http://example.com/softwarepackage.tar.gz";  
label="Main Server" />
http://example2.com/softwarepackage.tar.gz";  
label="California Server" />
http://example3.com/softwarepackage.tar.gz";  
label="European Server" />




or this:

http://example.com/ 
softwarepackage.tar.gz" type="application/x-gzip" x:group="software- 
package" x:label="Main Server" nf:follow="no" >
http://example2.com/softwarepackage.tar.gz";  
x:label="California Server" />
http://example3.com/softwarepackage.tar.gz";  
x:label="European Server" />

Re: Sponsored Links and other link extensions

[James M Snell]

James Holderness wrote:



James M Snell wrote:

http://example.com/softwarepackage.zip"; 
type="application/zip" x:group="software-package" nf:follow="no">
 http://example2.com/softwarepackage.zip"; 
title="California Server" />
 http://example3.com/softwarepackage.zip"; 
title="European Server" />


href="http://example.com/softwarepackage.tar.gz"; 
type="application/x-gzip" x:group="software-package" nf:follow="no">
 http://example2.com/softwarepackage.tar.gz"; 
title="California Server" />
 http://example3.com/softwarepackage.tar.gz"; 
title="European Server" />





I'm not quite clear how the nofollow attribute is supposed to work 
here. If a feed producer wants to allow automatic downloads, but is 
providing the file in multiple formats (only one of which is needed) 
how should that be expressed? As you have it at the moment, the client 
can't auto-download at all. Should he just leave nofollow off and rely 
on the client to download only one?


In this particular example yes.  The idea was to demonstrate that there 
are means by which smart client behavior can be controlled given the 
concerns about potential bandwidth abuse.  Dumb clients continue to act 
the way they would today.


Also, assuming the title on the main link is supposed to describe the 
download file itself, there appears to be no way to inform the user of 
the mirror location of the main URI. Without a location name of some 
sort, the user can't make an informed decision about which mirror 
would be best to use. Perhaps something along the line of Antone's 
"label" suggestion might help here.



I could just do this:

http://example.com/softwarepackage.tar.gz"; 
type="application/x-gzip" x:group="software-package" nf:follow="no" >
http://example.com/softwarepackage.tar.gz"; label="Main 
Server" />
http://example2.com/softwarepackage.tar.gz"; 
label="California Server" />
http://example3.com/softwarepackage.tar.gz"; 
label="European Server" />



- James

Re: Sponsored Links and other link extensions

[James Holderness]

James M Snell wrote:
http://example.com/softwarepackage.zip"; 
type="application/zip" x:group="software-package" nf:follow="no">
 http://example2.com/softwarepackage.zip"; 
title="California Server" />
 http://example3.com/softwarepackage.zip"; title="European 
Server" />


http://example.com/softwarepackage.tar.gz"; 
type="application/x-gzip" x:group="software-package" nf:follow="no">
 http://example2.com/softwarepackage.tar.gz"; 
title="California Server" />
 http://example3.com/softwarepackage.tar.gz"; 
title="European Server" />




I'm not quite clear how the nofollow attribute is supposed to work here. If 
a feed producer wants to allow automatic downloads, but is providing the 
file in multiple formats (only one of which is needed) how should that be 
expressed? As you have it at the moment, the client can't auto-download at 
all. Should he just leave nofollow off and rely on the client to download 
only one?


Also, assuming the title on the main link is supposed to describe the 
download file itself, there appears to be no way to inform the user of the 
mirror location of the main URI. Without a location name of some sort, the 
user can't make an informed decision about which mirror would be best to 
use. Perhaps something along the line of Antone's "label" suggestion might 
help here.


Regards
James

Re: Sponsored Links and other link extensions

[Antone Roundy]

On Oct 25, 2005, at 11:04 AM, James M Snell wrote:

All-in-one example

The x:group attribute links the two alternates into a single  
grouping; the x:mirror specifies the mirrors for each link.   
nf:follow="no" is my Atom Link No Follow extension that tells  
clients not to automatically download the enclosure.  Dumb clients  
will see what amounts to the current status quo, two different  
enclosures of different types.  Smart clients will see the mirrors,  
the grouping and the no-follow instruction.


http://example.com/softwarepackage.zip";  
type="application/zip" x:group="software-package" nf:follow="no">
 http://example2.com/softwarepackage.zip";  
title="California Server" />
 http://example3.com/softwarepackage.zip";  
title="European Server" />


http://example.com/ 
softwarepackage.tar.gz" type="application/x-gzip" x:group="software- 
package" nf:follow="no">
 http://example2.com/softwarepackage.tar.gz";  
title="California Server" />
 http://example3.com/softwarepackage.tar.gz";  
title="European Server" />



Thoughts?


The only thing I would change is the name of x:mirror/@title to make  
it clear that it isn't intended(?) to replace the parent link's  
@title.  My current favorite name is "label".

Re: Sponsored Links and other link extensions

[James M Snell]

Hmmm...



Mirrors:



 



Alternates:





All-in-one example

The x:group attribute links the two alternates into a single grouping; 
the x:mirror specifies the mirrors for each link.  nf:follow="no" is my 
Atom Link No Follow extension that tells clients not to automatically 
download the enclosure.  Dumb clients will see what amounts to the 
current status quo, two different enclosures of different types.  Smart 
clients will see the mirrors, the grouping and the no-follow instruction.


http://example.com/softwarepackage.zip"; 
type="application/zip" x:group="software-package" nf:follow="no">
 http://example2.com/softwarepackage.zip"; 
title="California Server" />
 http://example3.com/softwarepackage.zip"; 
title="European Server" />


http://example.com/softwarepackage.tar.gz"; 
type="application/x-gzip" x:group="software-package" nf:follow="no">
 http://example2.com/softwarepackage.tar.gz"; 
title="California Server" />
 http://example3.com/softwarepackage.tar.gz"; 
title="European Server" />



Thoughts?

- James

Re: Sponsored Links and other link extensions

[Antone Roundy]

On Oct 25, 2005, at 12:59 AM, A. Pagaltzis wrote:

I am asking if is there a generic way for an application to
implement alternate-link processing that gives sensible behaviour
for any type of main link. If an implementor has to support
alternative links explicitly for each type of main link, where’s
the difference to having specific relationships for alternative
links depending on the main link type?


Here are a few examples of generic processing algorithms an  
application might use:


Mirrors:
1) Randomly selecting a mirror to download from, thus helping to  
spread the bandwidth usage among them.
2) Try the main link, and if the DNS lookup fails, or a connection  
can't be made or something, automatically try the next one.
3) Ping each of the servers in the background, and if the user clicks  
the link, use the fastest one.


Alternates:
1) Have a prioritized list of formats, and choose the link that  
points to the highest priority format.
2) Of all the formats the app supports, choose the one with the  
smallest @length, if present.


Either one:
1) Show some sort of UI for selecting which link to follow (perhaps  
have the main link selected by default, but allow the user to select  
an alternate from the popup).


None of those ideas is necessarily tied to any particular link  
relation.  They might be more important for enclosures than any of  
the other relations that have been defined so far, and an application  
may or may not do some for enclosures that it doesn't do for some  
other specific link relations.  But again, it comes back to the yet  
unanswered question, are there any disadvantages to keeping it  
generic?  I haven't heard anyone suggest any downside yet--only that  
some people can't imagine why anyone would want to use alternative  
links for anything but enclosures.

Re: Sponsored Links and other link extensions

[Eric Scheid]

On 25/10/05 5:06 PM, "A. Pagaltzis" <[EMAIL PROTECTED]> wrote:

> Is providing a @title an option that a lot of people would use
> and/or someone out there cannot do without?

In Atom 1.0  not enough deployment to say

In HTML ... *lots* of current practice of labelling mirrors with the org
name and/or location. Lots.

e.

Re: Sponsored Links and other link extensions

[Eric Scheid]

On 25/10/05 5:17 PM, "Henry Story" <[EMAIL PROTECTED]> wrote:

>>> http://example.com/
>>> file.mp3" xml:id="x-file">
>>> http://www2.example.com/file.mp3"; />
>>> http://www3.example.com/file.mp3"; />
>>> 
>>> 
>> 
>> It¹s a lot more verbose and you have to fiddle with nesting.
>> 
>> What do you get in return? ³It looks more XMLish²?
>> 
> 
> yes!? We are using xml!

not only that, but if someone wants to write another extension (gasp!), it
would be very easy to fold it in, using native XML methods...







(not that I can think of any such extensions, but why be a bastard to future
inventors and innovators?)

e.

Re: Sponsored Links and other link extensions

[Eric Scheid]

On 25/10/05 4:59 PM, "A. Pagaltzis" <[EMAIL PROTECTED]> wrote:

> I am asking if is there a generic way for an application to
> implement alternate-link processing that gives sensible behaviour
> for any type of main link.





couldn't get more generic than that.

read it as: here is a link (ooh, look, some alternate href's!)

> If an implementor has to support alternative links explicitly for each type of
> main link, where¹s the difference to having specific relationships for
> alternative links depending on the main link type?
> 
good point.

e.

Re: Sponsored Links and other link extensions

[Henry Story]

On 24 Oct 2005, at 22:59, A. Pagaltzis wrote:



* Antone Roundy <[EMAIL PROTECTED]> [2005-10-24 22:35]:


Interesting. Filling an attribute with a list of URIs doesn't
really appeal to me though.


+100 (me and all my co-voting cats)


How about this:

http://example.com/
file.mp3" xml:id="x-file">
http://www2.example.com/file.mp3"; />
http://www3.example.com/file.mp3"; />




It’s a lot more verbose and you have to fiddle with nesting.

What do you get in return? “It looks more XMLish”?



yes!? We are using xml!





Sounds good, but you may have noticed above that I used a
prefix not specific to enclosures--there's no reason to tie
this all to one particular type of link (nor to make it look
as if it were tied to one specific link type). So the other
link might, for example, be:



I don’t know if striving for generality in this fashion without
a practical need is worthwhile. It smells of architecture
astronautics for a reason I can’t particularly pinpoint. So maybe
my instinct is wrong.



maybe :-)
A million cats can't be wrong.





Note that I changed "alternative-to" to "primary" just because
it's shorter and one word.



Works for me.

Regards,
--
Aristotle Pagaltzis // 

Re: Sponsored Links and other link extensions

[A. Pagaltzis]

* Eric Scheid <[EMAIL PROTECTED]> [2005-10-25 06:35]:
> There's another problem with this:
> 
> >   @encl:mirrors="http://www2.example.com/file.mp3
> >http://www3.example.com/file.mp3";
> 
> ... how do you attach @title to each URI,
> 
> for example @title="Blah blah -- European Mirror".

You can’t. My assumption was that supplying divergent metadata
for what are supposed to be bit-for-bit copies of a file is not
particularly useful, whereas having no such option serves as a
hint that the copies are not to be considered as independent
entities.

Is providing a @title an option that a lot of people would use
and/or someone out there cannot do without?

Regards,
-- 
Aristotle Pagaltzis // 

Re: Sponsored Links and other link extensions

[A. Pagaltzis]

* Antone Roundy <[EMAIL PROTECTED]> [2005-10-25 06:30]:
> I'm not sure I understand what you're saying. Are you saying
> that one might do this if they want and alternate of a "next"
> link?
> 
> 
> 

No, not at all.

> If that's what you mean, then sure, the code for that would be
> the same as for:
> 
> 
> 
> 
> ...but it would sure look odd. I see no advantage to naming
> these things in terms of enclosures.

I am asking if is there a generic way for an application to
implement alternate-link processing that gives sensible behaviour
for any type of main link. If an implementor has to support
alternative links explicitly for each type of main link, where’s
the difference to having specific relationships for alternative
links depending on the main link type?

Regards,
-- 
Aristotle Pagaltzis //