* Eric Scheid [EMAIL PROTECTED] [2005-08-06 05:40]:
either that or a flag that says this is dereferenceable, but
that is ugly and doesn't let the publisher have a link with
both.
would it be useful? google does interesting things by crawling
links, so do many other link crawling tools.
As
* Eric Scheid [EMAIL PROTECTED] [2005-08-05 19:35]:
... and it's too late to write a pace with atom:idref, and
wording saying an atom:link must have at least either an
atom:href attribute or an atom:idref attribute. That is, one or
both but not neither.
I dunno if it’d be such a great idea
A. Pagaltzis wrote:
* Eric Scheid [EMAIL PROTECTED] [2005-08-05 19:35]:
... and it's too late to write a pace with atom:idref, and
wording saying an atom:link must have at least either an
atom:href attribute or an atom:idref attribute. That is, one or
both but not neither.
I dunno
On 11/8/05 3:20 PM, A. Pagaltzis [EMAIL PROTECTED] wrote:
As long as producers throw in atom:[EMAIL PROTECTED]'related'] pointers
to the source as well, that base is covered anyway.
I'd prefer to see atom:[EMAIL PROTECTED]in-reply-to].
Of course it's related. All links in an entry point to
On 5/8/05 3:07 PM, James M Snell [EMAIL PROTECTED] wrote:
thr:in-reply-to id=urn:foo:1 type=application/atom+xml
src=http://www.example.com/atom; /
how about this instead
link rel=in-reply-to
href=http://www.example.com/atom;
type=application/atom+xml
* James M Snell [EMAIL PROTECTED] [2005-08-05 07:15]:
Does this work or do I need to be taken out and flogged again?
Absolutely that does work for me.
(Sorry for the curt reply – I am off to catch a plane in a few
minutes and won’t have ’net for a week. Tried to get this out
before I am gone.
On Aug 4, 2005, at 10:59 PM, Eric Scheid wrote:
link rel=in-reply-to
href=http://www.example.com/atom;
type=application/atom+xml
thread:idref=urn:foo:1 /
this way processors that have a basic understanding of what a
link is can
still do something useful.
On 5/8/05 9:55 PM, Tim Bray [EMAIL PROTECTED] wrote:
Uh, consider
link rel=ultimate-source-of-all-evil-STAY-AWAY
href=http://example.org/evil; /
What useful thing is there that software could sanely do, knowing
only that something is a link? -Tim
not knowing what that particular
On 5/8/05 7:48 PM, A. Pagaltzis [EMAIL PROTECTED] wrote:
link rel=in-reply-to
href=http://www.example.com/atom;
type=application/atom+xml
thread:idref=urn:foo:1 /
this way processors that have a basic understanding of what a
link is can still do
I definitely appreciate all of the feedback on this. The conversation
has definitely been helpful. Personally, however, I think that the
elegance and simplicity of in-reply-to and replies link rel values
trumps defining them as elements in a separate namespace or an otherwise
perfectly
* James M Snell [EMAIL PROTECTED] [2005-08-04 21:15]:
Personally, however, I think that the elegance and simplicity
of in-reply-to and replies link rel values trumps defining them
as elements in a separate namespace or an otherwise perfectly
engineered solution. As for specifying the source
A. Pagaltzis wrote:
* James M Snell [EMAIL PROTECTED] [2005-08-04 21:15]:
Personally, however, I think that the elegance and simplicity
of in-reply-to and replies link rel values trumps defining them
as elements in a separate namespace or an otherwise perfectly
engineered solution. As for
On Sunday, July 31, 2005, at 10:24 AM, A. Pagaltzis wrote:
* Antone Roundy [EMAIL PROTECTED] [2005-07-31 01:15]:
I could add more, but instead, here's my suggestion for
replacing that sentence:
If the resource being replied to is an atom:entry, the
value of the href attribute MUST be
* Antone Roundy [EMAIL PROTECTED] [2005-08-01 18:30]:
On Sunday, July 31, 2005, at 10:24 AM, A. Pagaltzis wrote:
This undermines the purpose of the link.
I'd say that not being able to tell whether @href in
[EMAIL PROTECTED]in-reply-to] is dereferencable or not is what
undermines link.
* David Powell [EMAIL PROTECTED] [2005-07-31 02:20]:
Saturday, July 30, 2005, 9:55:33 PM, Antone Roundy wrote:
link rel=in-reply-to ...
link rel=in-reply-to-feed ... /
/link
I'm not at all keen on extending the link element in this way.
Atom Publishing Servers that don't know
* James M Snell [EMAIL PROTECTED] [2005-07-31 00:30]:
I agree. I'd much rather avoid introducing a new namespace for
this tho. Nested link elements if just fine I think
link rel=in-reply-to href=...
link rel=source href=... /
/link
Nope. As I just wrote in reply to David Powell, sec. 6
* Antone Roundy [EMAIL PROTECTED] [2005-07-31 01:15]:
I could add more, but instead, here's my suggestion for
replacing that sentence:
If the resource being replied to is an atom:entry, the
value of the href attribute MUST be the atom:id of the
atom:entry. If the value of the
Sunday, July 31, 2005, 4:47:44 PM, A. Pagaltzis wrote:
Strictly speaking, per Extensions To the Atom Vocabulary (sec.
6.2), an Atom processor must treat the nested link as it would
treat any other Structured Extension Element (sec. 6.4.2).
Only child elements of atom:entry, atom:feed, and
On 30 Jul 2005, at 1:38 am, A. Pagaltzis wrote:
* James M Snell [EMAIL PROTECTED] [2005-07-30 01:40]:
It's really just a hint as to where original entries MIGHT be
found.
“originally-at?”
source?
Graham
* James M Snell [EMAIL PROTECTED] [2005-07-30 18:10]:
Yeah, source is likely the most logical choice, but I didn't
want to confuse folks with a link @rel=source that has a
different meaning from atom:source.
An argument by way of which I came around to Antone’s suggested
“start-of-thread,”
On Saturday, July 30, 2005, at 02:38 PM, A. Pagaltzis wrote:
* James M Snell [EMAIL PROTECTED] [2005-07-30 18:10]:
Yeah, source is likely the most logical choice, but I didn't
want to confuse folks with a link @rel=source that has a
different meaning from atom:source.
An argument by way of
* Justin Fletcher [EMAIL PROTECTED] [2005-07-30 23:25]:
I'm quite happy with 'replies-source' because it does not
indComparing to mail seems to be a reasonable thing to do -
mail has a considerable amount of prior implementation and
understanding from which concepts can be drawn. However,
I agree. I'd much rather avoid introducing a new namespace for this
tho. Nested link elements if just fine I think
link rel=in-reply-to href=...
link rel=source href=... /
/link
Using source in this context I think avoids the potential confusion had
the link appeared without nesting.
One challenge is that for anything besides references to Atom entries,
there is no guarantee that in-reply-to links will be non-traversable.
For instance, if someone were to go and define a behavior for using
in-reply-to with RSS, the href of the link may point to the same URL
that the RSS
On Saturday, July 30, 2005, at 04:37 PM, James M Snell wrote:
One challenge is that for anything besides references to Atom entries,
there is no guarantee that in-reply-to links will be non-traversable.
For instance, if someone were to go and define a behavior for using
in-reply-to with
Saturday, July 30, 2005, 9:55:33 PM, Antone Roundy wrote:
link rel=in-reply-to ...
link rel=in-reply-to-feed ... /
/link
I'm not at all keen on extending the link element in this way. Atom
Publishing Servers that don't know about this extension that receive
an entry containing
Sunday, July 31, 2005, 1:09:44 AM, I wrote:
I don't believe that atom:link _isn't_ usefully extensible other than by
er, that should be is
--
Dave
On 31/7/05 7:47 AM, A. Pagaltzis [EMAIL PROTECTED] wrote:
I¹m -1 on using ³replies-source²; I should have said so more
explicitly before. To me it is non-sensical, as it parses as ³the
source of replies,² which is the opposite relationship of what
it¹s supposed to express. It¹s not where the
* Antone Roundy [EMAIL PROTECTED] [2005-07-29 02:40]:
On Thursday, July 28, 2005, at 05:58 PM, James M Snell wrote:
root is now called replies-source... which is a horrible
name but I'm not sure what else to call it
How about start-of-thread.
Or maybe “parent-entries?”
Regards,
--
On Friday, July 29, 2005, at 02:41 PM, A. Pagaltzis wrote:
* Antone Roundy [EMAIL PROTECTED] [2005-07-29 02:40]:
On Thursday, July 28, 2005, at 05:58 PM, James M Snell wrote:
root is now called replies-source... which is a horrible
name but I'm not sure what else to call it
How about
Right. Nor is there any guarantee that the referenced entity will
actually contain the original entry... e.g. it's possible that it could
point to a feed that has been updated such that the original entry has
already moved off of it. It's really just a hint as to where original
entries
On Thursday, July 28, 2005, at 05:58 PM, James M Snell wrote:
* root is now called replies-source... which is a horrible name
but I'm not sure what else to call it
How about start-of-thread.
32 matches
Mail list logo
