Subject: IANA registry vs. URIs

From: Paul Hoffman / IMC <[email-masked]>
Date: Tue, 19 Oct 2004 10:16:16 -0700

Wearing my co-chair and non-impelenter hats:

The major difference between defining link type in an IANA registry 
or by URI is interoperability. If something is in the IANA registry 
and we have specified that you have to define what your registered 
type means, then an implementer can look in the IANA registry and 
figure out what this new link type means. They can't do that with a 
URI unless the URI dereferences to a description of what the link 
type means.

The assumption that many people are making here is that the 
dereferencing will happen correctly for all time, and that the 
technical content at the URI will not change. IETF experience has 
proven those assumptions to be wrong again and again. A non-trivial 
example is that a viewer producer comes up with a new link type, 
bakes it into their viewer, and publishes the spec at the URI. A few 
months later, someone points out something wrong in their spec so 
they change it. Everyone who read the spec before the change is now 
screwed. Another non-trivial example is that the company forgets to 
renew its domain name and the link dies.

One way to get around the problem of URIs no longer dereferencing, or 
changing, is for people who rely on the link to copy the contents and 
republish them in a well-known place. For instance, a vendor might 
create a publicly-accessible document that says "our product knows 
how to use link types A, B, and C, and here is what we are using as 
our basis for interpreting them". Assuming that the documents are 
longer-lived than the URIs and can be found by future implementers, 
this fixes both problems. Of course, both those assumptions have 
difficulty.

Getting a new type registered in the IANA registry can definitely a 
pain in the butt, and some folks will simply not do it but will 
create new link types anyway. The IETF has lots of experience with 
this as well. We can make the IANA registration process as easy or as 
hard as we want, as long as a secretarial person at IANA can follow 
what we say.

The question comes down to: is the high interoperability value of 
having a stable repository of definitions of link types worth the 
high cost of commonly-used link types that lose their definitions 
plus the cost of developers that don't bother to register at all? 
Historically in the IETF, the answer to similar questions has been 
"yes", but we can certainly answer that differently if we think the 
costs outweigh the benefits of an IANA registry.

--Paul Hoffman, Director
--Internet Mail Consortium

---

From: Robert Sayre <[email-masked]>
Date: Tue, 19 Oct 2004 14:00:29 -0400

Paul Hoffman / IMC wrote:

> 
> The major difference between defining link type in an IANA registry or 
> by URI is interoperability. If something is in the IANA registry and we 
> have specified that you have to define what your registered type means, 
> then an implementer can look in the IANA registry and figure out what 
> this new link type means. They can't do that with a URI unless the URI 
> dereferences to a description of what the link type means.
> 
> dereferencing will happen correctly for all time, and that the technical 
> content at the URI will not change. IETF experience has proven those 
> assumptions to be wrong again and again. 

That's not the assumption that I am making. We are not talking about 
automagical configuration of unknown links. What we are talking about is 
a way for people to formulate ad-hoc links that don't collide with other 
people's ad-hoc links.

X-MailerURI: http://example.org/mailer

becomes

http://example.org-MailerURI: http://example.org/mailer

That's it.

Robert Sayre

---

From: Paul Hoffman / IMC <[email-masked]>
Date: Tue, 19 Oct 2004 11:07:10 -0700

At 2:00 PM -0400 10/19/04, Robert Sayre wrote:
>automagical configuration of unknown links.

Agree, but...

>  What we are talking about is a way for people to formulate ad-hoc 
>links that don't collide with other people's ad-hoc links.

And how would a Atom reader know what to do with the ad-hoc link? 
Where would the interoperability for that new link type come from? Or 
are you saying that there is no expectation of interoperability for 
these new link types?

>http://example.org-MailerURI: http://example.org/mailer

Well, heck, that's easy. We can add a sentence to Atom that says "any 
link type name that begins with the string 'x-' is for private use 
only." Then we're in the same mess as every other IETF protocol from 
the last 15 years that have private extension, but at least we're 
doing it the same way.

--Paul Hoffman, Director

---

From: Danny Ayers <[email-masked]>
Date: Tue, 19 Oct 2004 20:12:45 +0200

I'm sorry Paul, but I don't think this is a fair comparison at all:

If something is in the IANA registry
> URI unless the URI dereferences to a description of what the link

1. You can't take an IANA registered string and dereference it to find
its meaning.

2. If dereferencing was a necessary requirement of name definitions,
then anything that relied on XML Namespaces would fail to work.

Even if your comparison worked, then I would personally still prefer
to see URIs used, because the registration barrier is high enough that
I think people would simply tend to ignore it (like URI scheme
registration). Whereas the barrier to using URIs is fairly low -
domain name registration is relatively cheap.

For example, when defining RDF vocabularies I've personally had
absolutely no temptation to use http://w3.org/rdf/MyStuff when my
alternatives have been e.g. http://dannyayers.com/rdf/MyStuff or e.g.
http://purl.org/stuff/rdf/MyStuff, it's more natural to use an
alternative that coincidentally does provide the necessary
partitioning.

Cheers,
Danny.

-- 

http://dannyayers.com

---

From: Robert Sayre <[email-masked]>
Date: Tue, 19 Oct 2004 15:00:34 -0400

Paul Hoffman / IMC wrote:
> And how would a Atom reader know what to do with the ad-hoc link? Where 
> would the interoperability for that new link type come from? Or are you 
> saying that there is no expectation of interoperability for these new 
> link types?
> 

An Atom reader should be able to safely dereference the linked resource, 
if the user is interested in the title. The link will also have a MIME type.

> only." Then we're in the same mess as every other IETF protocol from the 
> last 15 years that have private extension, but at least we're doing it 
> the same way.

Given current practice in syndication, I don't think we have a choice. 
There will be private extension. Second, your suggestion assumes that 
link types will be in attribute values, rather than be elements themselves.

We have to support XML Namespaces, right? Why do we need multiple 
collision-prevention mechanisms? I guess you could say my POV is that we 
have three choices:

* Use XML Namespaces.
* Drop XML Namespaces, and require "x-" or IANA registration for every
   element used in Atom.
* Do both

I know we aren't supposed to be discussing syntax, but I think we've 
gotten ourselves into this mess because of the syntax of the link 
element. I mean, we could define the Text construct similarly:

<text role="title">...
<text role="summary">...
<text role="copyright">...

Robert Sayre

---

From: Dare Obasanjo <[email-masked]>
Date: Tue, 19 Oct 2004 12:06:56 -0700 (PDT)

> are you saying that there is no expectation of

Expecting an Atom reader to some how "learn" what to
do with an ad-hoc link simply given a URI is venturing
on AI. 

> the last 15 years that have private extension, but

URIs are supposed to reduce the likelihood of
collision between parties creating custom links.
However as you point out experience has shown that
such collisions rarely occur in practice as is
evidenced by the various IETF specs which use the 'x-'
prefix extension mechanism. 

=====
THINGS TO DO IF I BECOME AN EVIL OVERLORD #23
I will keep a special cache of low-tech weapons and train my troops in their use. That way -- even if the heroes manage to neutralize my power generator and/or render the standard-issue energy weapons useless -- my troops will not be overrun by a handful of savages armed with spears and rocks.

_______________________________
Do you Yahoo!?
Declare Yourself - Register online to vote today!
http://vote.yahoo.com

---

From: Paul Hoffman / IMC <[email-masked]>
Date: Tue, 19 Oct 2004 12:28:47 -0700

>1. You can't take an IANA registered string and dereference it to find

Of course not. You have to go look in the IANA registry. It's in a 
well-known and stable location that is relied on by every implementer 
of IETF protocols.

>then anything that relied on XML Namespaces would fail to work.

You're missing the point completely. Link *types* have some 
semantics. The URL that is used for the extension *of the type* is 
what tells you the semantics.

At 3:00 PM -0400 10/19/04, Robert Sayre wrote:
>An Atom reader should be able to safely dereference the linked 
>resource, if the user is interested in the title. The link will also 
>have a MIME type.

Fully agree. My statement is about whether we care about the 
semantics of the new types.

>>Well, heck, that's easy. We can add a sentence to Atom that says 
>>"any link type name that begins with the string 'x-' is for private 
>>use only." Then we're in the same mess as every other IETF protocol 
>>from the last 15 years that have private extension, but at least 
>>we're doing it the same way.
>
>Given current practice in syndication, I don't think we have a 
>choice. There will be private extension. Second, your suggestion 
>assumes that link types will be in attribute values, rather than be 
>elements themselves.

True, but it could be extended to the elements in the same way.

>We have to support XML Namespaces, right?

Of course.

>  Why do we need multiple collision-prevention mechanisms?

We are not talking only about collision-prevention: we are also 
talking about the semantics of the extended link types. Or, at least 
I thought we were talking about that. If we don't care anything about 
the semantics of them, then you can ignore everything I said. But, of 
course, the extensions will be nearly useless because Atom readers 
won't be able to do anything with the link other than to let the user 
deference it without any context ("is this about the entry, is this 
with the entry, is this a picture of the person who wrote the entry, 
is this the sound he made as he typed the entry, ...").

>do with an ad-hoc link simply given a URI is venturing

Fully agree. The registry or deferencable link type names are for the 
humans like you who are updating their Atom reader software to handle 
the new link types.

--Paul Hoffman, Director

---

From: "Roy T. Fielding" <[email-masked]>
Date: Tue, 19 Oct 2004 12:37:49 -0700

> the last 15 years that have private extension, but at least we're 

No, then you would just have a broken protocol, like all of the ones
in the IETF that specify "x-".  The point of using URIs is to provide
hierarchical delegation down to the point of easy avoidance of
name collisions.  x-prefixes does nothing to help that and, in fact,
is known to be actively harmful to interoperability.

The reasonable alternative is to make the field a URI-reference
with a base URI equal to that of the IANA registry.  That way, people
who take the time to register a valuable name are rewarded with a
short syntax, while the folks who want complete control of the
specificity of their link types can mint their own URIs.  Eventually,
life will sort itself out and all of the significantly deployed types
will become registered, and none of the insignificantly deployed
types will collide with each other.

Cheers,

Roy T. Fielding                            <http://roy.gbiv.com/>
Chief Scientist, Day Software              <http://www.day.com/>

---

From: Bjoern Hoehrmann <[email-masked]>
Date: Tue, 19 Oct 2004 21:43:09 +0200

>URI unless the URI dereferences to a description of what the link 

A registry further helps to answer questions such as:

  * Is there already a link type with the desired "meaning"?
  * Which link types can I use to do what I want?
  * Which link types should be implemented in my product?
  * What do people think about my proposed extension?

And it would yield in a number of desired properties of new link types
such as neutrality (no need to put names of persons or organization in
the document to use the extension).

---

From: "Roy T. Fielding" <[email-masked]>
Date: Tue, 19 Oct 2004 12:45:48 -0700

> collision-prevention mechanisms?

Because use of qnames in content should be avoided at all costs.
XML Namespaces are a tuple-space for XML parsers. Using tuple-spaces
for hierarchical names is a bad idea outside the context of
SGML/XML restrictions on NAME characters, and should not be
repeated anywhere else.

....Roy

---

From: Robert Sayre <[email-masked]>
Date: Tue, 19 Oct 2004 15:44:07 -0400

Paul Hoffman / IMC wrote:

> 
> We are not talking only about collision-prevention: we are also talking 
> about the semantics of the extended link types. Or, at least I thought 
> we were talking about that. If we don't care anything about the 
> semantics of them, then you can ignore everything I said. But, of 
> course, the extensions will be nearly useless because Atom readers won't 
> be able to do anything with the link other than to let the user 
> deference it without any context ("is this about the entry, is this with 
> the entry, is this a picture of the person who wrote the entry, is this 
> the sound he made as he typed the entry, ...").
> 

Ok, I understand what you mean now. I noticed as I was making a demo of 
the Mozilla feature that @rel in HTML is overloaded. It serves as a type 
and a human description. I think we should split them up.

Here's that demo:
http://franklinmint.fm/2004/10/19/links.html

Robert Sayre

---

From: Bjoern Hoehrmann <[email-masked]>
Date: Tue, 19 Oct 2004 21:50:31 +0200

>1. You can't take an IANA registered string and dereference it to find

Why not?

>then anything that relied on XML Namespaces would fail to work.

Did anyone propose this as an absolute requirement?

>domain name registration is relatively cheap.

Why does this matter exactly?

---

From: Danny Ayers <[email-masked]>
Date: Tue, 19 Oct 2004 22:59:23 +0200

> well-known and stable location that is relied on by every implementer

The inability to dereference was one of your main arguments against
URIs. I'm simply suggesting you apply the same criteria to both
options.

On the other hand, you could set up a well-known location for finding
URI semantics (though I don't actually think that would be good
approach beyond informative docs).

> what tells you the semantics.

Maybe I am missing the point, but as I understand the relevant
proposal (which I wrote) a URI will be used as an identifier for the
link type, in a similar way as an IANA-registered value would be. The
maintenance of the name is a separate issue from discovery of the
semantics of a particular type.

There is considerable prior art in the use of URIs for typing
link-like constructs [1], [2], [3]. I'm not aware of any that have
found IANA registration necessary.

I don't think it's strictly relevant, but discovery of the semantics
would probably be easier using a URI as it could /potentially/ be
deferenced (the spec could even mandate it) and standard techniques
such as RDDL, WSDL, RDF Schema and/or OWL used to provide semantics.
None of the IANA registries I've encountered have provided material in
a form that would be easy for an application to interpret.

>do with an ad-hoc link simply given a URI is venturing

"learn"?
At it's most sophisticated I think we're talking about the reader
downloading a plugin.
An Atom reader could fairly easily look up how to interpret an ad hoc
link type, it might even involve behaviour. But I think it would be a
stretch to call process/service identifiers AI.

Cheers,
Danny.

[1] http://www.w3.org/TR/xlink/
[2] http://www.topicmaps.org/xtm/1.0/#elt-subjectIndicatorRef
[3] http://www.w3.org/TR/rdf-schema/#ch_properties

-- 

http://dannyayers.com

---

From: Danny Ayers <[email-masked]>
Date: Tue, 19 Oct 2004 23:12:21 +0200

> >1. You can't take an IANA registered string and dereference it to find

Fair point. Try: "You can't take an arbitrary IANA registered string
and dereference it using any well-known protocol it to find its
meaning."

> Did anyone propose this as an absolute requirement?

No, but it formed a significant part of Paul's argument.

> Why does this matter exactly?

Standardization is useful for interoperability.

Cheers,
Danny.

-- 

http://dannyayers.com

---

From: Tim Bray <[email-masked]>
Date: Tue, 19 Oct 2004 14:29:55 -0700

> types will collide with each other.

I'll write up a Pace to formalize this proposal.  It sounds uncluttered 
and sane to me. -Tim

---

From: Danny Ayers <[email-masked]>
Date: Tue, 19 Oct 2004 23:50:22 +0200

> I'll write up a Pace to formalize this proposal.  It sounds uncluttered

Thanks. 

I don't see any harm in this approach, but have yet to see any
convincing argument as to why IANA registration should be needed, what
benefits it brings. Ok, there may be a predefined process for
registering names. But for the context of syndication it seems to be
just enough trouble that people ignore it (e.g. the feed: URI scheme).
A centralised location for documentation could be associated with the
Atom namespace(s).

Looking at Roy's prognosis: 

Eventually,
> > types will collide with each other.

What has actually been gained from the registration of the
significantly deployed types?

Cheers,
Danny.

-- 

http://dannyayers.com

---

From: Bjoern Hoehrmann <[email-masked]>
Date: Tue, 19 Oct 2004 23:48:15 +0200

>and dereference it using any well-known protocol it to find its

Google is a well-known protocol to find out about everything of common
interest. Typing `http://example.org/atom/link-type/foo` rather than
`google atom link type foo` into the address bar of my browser does not
buy me much if anything.

>Standardization is useful for interoperability.

Standardization by removing rules has an impact on interoperability?

---

From: Danny Ayers <[email-masked]>
Date: Wed, 20 Oct 2004 00:01:01 +0200

> `google atom link type foo` into the address bar of my browser does not

Nope, afraid you lost me there.

> Standardization by removing rules has an impact on interoperability?

Standardization by selecting rules that stand a good chance of being
followed has an impact on interoperability. Choosing rules that are
likely to be broken is likely to be counter-productive.

Cheers,
Danny.

-- 

http://dannyayers.com

---

From: Paul Hoffman / IMC <[email-masked]>
Date: Tue, 19 Oct 2004 15:03:15 -0700

At 10:59 PM +0200 10/19/04, Danny Ayers wrote:
>URIs.

No, it was not. For one thing, I am not arguing against URIs: I am 
exposing the costs. The costs that I brough up are the inability to 
be sure you can dereference over a long period of time, and that what 
you get when you dereference later. There is a big difference between 
that and "inability to dereference".

>  I'm simply suggesting you apply the same criteria to both
>options.

I am doing so. IANA is a long-lived and stable repository; a URI is 
not necessarily.

>approach beyond informative docs).

Sure; you could even call it IANA. :-)

>semantics of a particular type.

OK, then I am misunderstanding your proposal. Assume that I'm 
implementing an Atom reader and I see a URL for a link type 
extension: where do I find the semantics for that link type?

>found IANA registration necessary.

None of those appear to use URIs for extending the list of types that 
can be used, it appears. Why did you bring those up?

>such as RDDL, WSDL, RDF Schema and/or OWL used to provide semantics.

...which leads to the problems I brought up: URIs go away, and even 
when they don't go away, their content changes.

>a form that would be easy for an application to interpret.

As I have said many times, we can say exactly how we want the IANA 
registry to behave. The fact that it hasn't been done doesn't means 
that we can't do it.

>At it's most sophisticated I think we're talking about the reader

A plugin for what? We're talking about link *types* here. If I'm 
writing an Atom reader, I know what to do with the link and I don't 
need a plugin for it. However, I don't know how to present it to the 
user.

>link type, it might even involve behaviour.

At the URI? If not, where? And for how long will that work?

--Paul Hoffman, Director

---

From: Martin Duerst <[email-masked]>
Date: Wed, 20 Oct 2004 07:08:15 +0900

and sane to me. -Tim

Great. I proposed something like this before, pointing to the
input mode field in XForms.

Regards,    Martin.

---

From: Dare Obasanjo <[email-masked]>
Date: Tue, 19 Oct 2004 15:12:32 -0700 (PDT)

> stretch to call process/service identifiers AI.

And my predictable answer is if all an application has
to do is key off of some URI then know where to go to
download the code to learn how to consume that URI
then there is no difference between "link based
extensibility" and "extensiblity based on extension
elements in a third party namespace". 

Of course, this ignores the feasibility of actually
implementing such a mechanism. 

Without a clear definition of what is meant to be a
link then there is no difference between using link
elements for extensibility and using arbitrarily
structured extension elements for extensibility
besides an arbitrary syntactic restriction. 

=====

		
__________________________________
Do you Yahoo!?
Yahoo! Mail - You care about security. So do we.
http://promotions.yahoo.com/new_mail

---

From: Danny Ayers <[email-masked]>
Date: Wed, 20 Oct 2004 00:17:52 +0200

On Tue, 19 Oct 2004 15:03:15 -0700, Paul Hoffman / IMC <[email-masked]> wrote:

After all this, we may be talking at cross purposes -

> need a plugin for it. However, I don't know how to present it to the

Could you please provide a couple of simple examples, sorry, I've no
idea what you mean.

> At the URI? If not, where? And for how long will that work?

The URI identifies something. Using HTTP on it may give you an
interpretation, or you may get that information through other means
such as RDF Schema obtained from a repository.

Cheers,
Danny.

-- 

http://dannyayers.com

---

From: Robert Sayre <[email-masked]>
Date: Tue, 19 Oct 2004 18:24:14 -0400

Dare Obasanjo wrote:

> link...

Do the approaches and working code outlined at the following URIs 
qualify as a "clear definition"?

http://www.imc.org/atom-syntax/mail-archive/msg10669.html

Robert Sayre

---

From: Danny Ayers <[email-masked]>
Date: Wed, 20 Oct 2004 00:31:40 +0200

> elements in a third party namespace".

There isn't all that much difference. The syntax restrictions of the
link construct do signal that the app should  treat this as a link
construct, and identify the endpoints (subject and object) of the link
relationship. But that could be in other ways.

> implementing such a mechanism.

That would depend on what is expected of the implementation.

> besides an arbitrary syntactic restriction.

True, but  the definition could be anything from "a relationship
between the feed and the remote URI" onwards.

Cheers,
Danny.

-- 

http://dannyayers.com

---

From: "Roy T. Fielding" <[email-masked]>
Date: Tue, 19 Oct 2004 16:12:33 -0700

> significantly deployed types?

Bits on the wire.  They add up, quicker than you might imagine.

Oh, and general happiness, since some people will violently oppose
a method that is either only-IANA or only-URI.  Removing any technical
justification for their arguments brings world peace, so to speak.

....Roy

---

From: Bill de hÓra <[email-masked]>
Date: Wed, 20 Oct 2004 00:49:48 +0100

> dereferences to a description of what the link type means.

That's not true.

> content at the URI will not change. 

That's not an assumption I'm making. The dereference argument 
doesn't hold up imo.

> The question comes down to: is the high interoperability value of having 
> a stable repository of definitions of link types worth the high cost of 
> commonly-used link types that lose their definitions plus the cost of 
> developers that don't bother to register at all? Historically in the 
> IETF, the answer to similar questions has been "yes", but we can 
> certainly answer that differently if we think the costs outweigh the 
> benefits of an IANA registry.

For me, the issue with IANA v URis has to do with process. As for 
interop, neither URIs nor an IANA registry will of itself provide 
interop or consistent semantics for link typing; that is best 
supplied by a type system, whihc in turn implies we have a good 
abstraction for links.

cheers
Bill

---

From: Dare Obasanjo <[email-masked]>
Date: Tue, 19 Oct 2004 16:53:47 -0700 (PDT)

> qualify as a "clear definition"?

Nope. 

This is a code sample in Javascript or some similar
language using some object model I am not familiar
with. That doesn't strike me as a clear definition of
anything.  

> http://franklinmint.fm/2004/10/19/links.html

The screenshot is better. So what is the definition of
link the you suggest the Atom spec uses that ensures
that whenever a client puts a rel value for a link in
that drop down it is something that makes sense to the
user? For example, if 'schema' and 'stylesheet' were
handled in the same way I doubt most end users would
find that useful. 

I read
http://www.w3.org/TR/REC-html40/struct/links.html#h-12.1
and it contains a fairly straightforward definition of
what it means to be a link. However this seems to
conflict with the RDF-style extensibility Danny Ayers
has been arguing for with his various posts on this
thread and others. 

=====

---

From: Robert Sayre <[email-masked]>
Date: Tue, 19 Oct 2004 20:07:11 -0400

Dare Obasanjo wrote:

>>>Without a clear definition of what is meant to be
>>
>>a
>>
>>>link...
>>

No spec can guarantee that every rel value will be useful to every end 
user. For example, there's nothing stopping me from linking a P3P file 
in an HTML anchor.

What the spec can do is outline what <link> is for.

> what it means to be a link. 

So if we adopt that definition, you're ok with that?

> However this seems to

PaceMetaElement?

Robert Sayre

---

From: Eric Scheid <[email-masked]>
Date: Wed, 20 Oct 2004 10:09:18 +1000

> That's not an assumption I'm making. The dereference argument

The 'dereferencing' argument isn't really about actual dereferencing. It's
about finding information which describes what that link type means. Trees
vs forest.

With an IANA registry, it's possible to find what a given registered link
type is, who registered it, references to documentation, descriptions of
semantics and use, descriptions of limitations/restrictions, etc. All
assuming we set up the registry for this of course, as distinct from a
really simple registration that only lists the link type tokens and nothing
else.

With URI based link types there is only one place to look to find
information, and that place may be broken. You could try querying google
with the domain name of the URI and other bits of the URI ... good luck with
that though since google will only tell you what it knows, not what it
doesn't[1], and with what it does know it biases heavily towards what is
popular rather than authoritative.

e.

[1] I receive google alerts each week for content it finds each day with
keywords of interest to me, and while it does send me links to new websites
it is also only just now discovering some web pages which date back to 1997.

---

From: Eric Scheid <[email-masked]>
Date: Wed, 20 Oct 2004 10:10:25 +1000

On 20/10/04 9:49 AM, "Bill de hÓra" <[email-masked]> wrote:

> which in turn implies we have a good
> abstraction for links.

does anyone object to us working towards that goal then?

e.

---

From: Eric Scheid <[email-masked]>
Date: Wed, 20 Oct 2004 10:20:13 +1000

On 20/10/04 9:53 AM, "Dare Obasanjo" <[email-masked]> wrote:

> I read http://www.w3.org/TR/REC-html40/struct/links.html#h-12.1 and it
> contains a fairly straightforward definition of what it means to be a link.
> 

While PaceLinkPurpose is not perfect, is it heading in the right direction?

How can we fix PaceLinkPurpose to more clearly define this style (traversal)
of link?

> However this seems to conflict with the RDF-style extensibility Danny Ayers
> has been arguing for with his various posts on this thread and others.

I just took a quick look at PaceMetaElement, thinking it would be the sister
to PaceServiceElement in the context of PaceLinkPurpose. My bad ... sheesh,
that proposed syntax is scarily perverse (sorry!).

Again, how can we fix PaceMetaElement to more clearly define this style
(metadata) of link?

e.

---

From: Eric Scheid <[email-masked]>
Date: Wed, 20 Oct 2004 17:38:13 +1000

> `google atom link type foo` into the address bar of my browser does not

In October of 1999 I wrote an email to a public mailing list concerning
Lotus, Microsoft, and AOL preparing IM for the enterprise. I referenced a
CHI 99 paper by Tom Erickson in which he refers to "Socially Translucent
Systems". That term is explicitly mentioned in the email. That email message
was archived onto the web in October 1999.

Find it in google, if you can. Can't be that many web pages with that
particular constellation of keywords.

Once you've tried that, I'll tell you the URL in question. You can then pump
that URL into google and try clicking the three options it offers...

    Find web pages that are similar to ...
    Find web pages that link to ...
    Find web pages that contain the term ...

... and google will tell you that it knows absolutely nothing about that
URL. Zero, zip, nada.

Y'know, I learned a long time ago that just because someone talks fast it
doesn't mean they have all the answers. Google is capable of talking fast,
very fast, regurgitating what it knows about 4,285,199,774 web pages ...
doesn't mean it has the answers to what I want.

e.

---

From: Danny Ayers <[email-masked]>
Date: Wed, 20 Oct 2004 13:47:32 +0200

> has been arguing for with his various posts on this

Just for the record, I was strongly in favour of using the <link>
element as a point of extension firstly because the list of @rel
values was growing over time, and secondly as the mechanism would
cover a significant part of the structured extensibility RSS 1.0 gains
from RDF.

If <link> is refactored as has been discussed (<service> etc), and
there are other routes to extensibility under discussion, I don't
really have any major objection to what remains being
HTML-<link>-like.

I'm still not sure it's entirely appropriate, as Atom is more
data-oriented (for want of a better divide) that HTML, so the
doc-oriented usage in Moz doesn't seem to mesh well. But what's left
of this issue is at its heart only about element naming, not a big
deal.

Cheers,
Danny.

-- 

http://dannyayers.com

---

From: Danny Ayers <[email-masked]>
Date: Wed, 20 Oct 2004 14:00:28 +0200

> PaceMetaElement?

After RDF/XML was taken off the table early on, that kind of approach
did appeal to me (see [1]). It does have a precedent in HTML, SVG etc
etc. But I've come to the view that it's altogether an ugly approach,
as it's adding an extra layer where there doesn't need to be one. The
elements within an <entry> are descriptions of the entry, it's already
meta.

So I'd favour something more along the lines of the structural
relationships discussed (but never Pace'd) a week or so ago (must
find...)

Cheers,
Danny.

[1] http://www.intertwingly.net/wiki/pie/SyntaxExtensionMechanism

-- 

http://dannyayers.com

---

From: Danny Ayers <[email-masked]>
Date: Wed, 20 Oct 2004 14:05:44 +0200

> Bits on the wire.  They add up, quicker than you might imagine.

I don't see a cause and effect there...

> justification for their arguments brings world peace, so to speak.

...but I can't argue with that.

Cheers,
Danny.

---

From: Antone Roundy <[email-masked]>
Date: Wed, 20 Oct 2004 07:58:34 -0600

> of this issue is at its heart only about element naming, not a big
The Mozilla approach shows exactly what I'd like to see applications 
able to do with <link>, the difference being that in the case of Atom, 
the spec should be where things like stylesheets are removed from the 
list.  In other words, "stylesheet" et al should not be allowed into 
@rel.  Allow me to repeat in this context what I've said on this 
subject before.

In most cases, webmasters don't link to stylesheets so that people can 
see the stylesheet, but so that browsers will format the webpage based 
on it.  When they DO want people to SEE the stylesheet, they link to it 
with <a>, not with <link>.  In the same way, Atom publishers should 
only put things into <atom:link> that they want people to be able to 
traverse a link directly to. This could include another feed, perhaps 
an atom:entry (if we decide an entry can be a document element), a 
webpage, a particular anchor within a webpage, a PDF file, a JPEG 
image, etc.  A JPEG image is another example of where it is the 
publisher's intention that governs whether to use <atom:link> or some 
other mechanism.  In some cases, the publisher intends for an image to 
be displayed within a webpage.  In those cases they use <img>.  In 
other cases, they intend it to be displayed by itsself.  In those 
cases, they use <a>.  as with stylesheets, <atom:link> is for the <a> 
case, not the <img> case.

Whatever spec text we come up with to define what an atom:link is, 
perhaps a PROSE example or two like the above discussion of stylesheets 
and images would be advantageous, just to be sure that people 
understand.  I'll have to think on some language for PaceLinkPurpose 
based on the above...

---

From: Danny Ayers <[email-masked]>
Date: Wed, 20 Oct 2004 16:37:37 +0200

Quick practical questions on this approach. Let's say the linked
information is an XSLT-transformed version of the feed, say into
docbook format.

feed is at http://example.org/feed.atom
stylesheet at http://example.org/atom2docbook.xsl

How would you express that? 
What do you think a typical client might display, and what behaviour
might be available?

Now say you want to say that a particular entry is associated with a
particular category in a remotely-defined scheme.

scheme: http://www.flickr.com
category: http://www.flickr.com/photos/tags/kitten/

Again, how would you express that? 
What do you think a typical client might display, and what behaviour
might be available?

Cheers,
Danny.

-- 

http://dannyayers.com

---

From: Robert Sayre <[email-masked]>
Date: Wed, 20 Oct 2004 11:34:30 -0400

> information is an XSLT-transformed version of the feed, say into

What's the URI of the XSLT-transformed version?

> What do you think a typical client might display, and what behaviour

Some other tag.

Robert Sayre

---

From: Antone Roundy <[email-masked]>
Date: Wed, 20 Oct 2004 09:38:28 -0600

> What do you think a typical client might display, and what behaviour

Solution A: Use some other element--"you can tranform my parent to  
such-and-such type using such-and-such stylesheet":
	<transform stylesheet="http://example.org/atom2docbook.xsl"  
title="Convert to DocBook" type="(DocBook's MIME type...if it has one)"  
/>.

	...or "you can tranform the thing pointed to by @href to such-and-such  
type using such-and-such stylesheet":
	<transform href="http://example.org/feed.atom"  
stylesheet="http://example.org/atom2docbook.xsl" title="Convert to  
DocBook" type="(DocBook's MIME type)" />

Solution B: Link to an external service that does such transformations:
	<link  
href="http://example.org/transform?src=http://example.org/ 
feed.atom&amp;stylesheet=http://example.org/atom2docbook.xsl" ... />

Solution C: Amend atom:link to do it as follows (This would be slightly  
weird if linking to a transformation of oneself, because what would you  
put into @rel?  "alternate"?  Until one of the tranformations was  
applied, it wouldn't be an alternate--it would be more like "self".):
	<link href="http://example.org/feed.atom" type="application/atom+xml">
		<transform type="(docbook's type)"  
stylesheet="http://example.org/atom2docbook.xsl" title="DocBook" />
		<transform type="application/rss+xml"  
stylesheet="http://example.org/atom2rss.xsl" title="RSS 2.0" />
	</link>

Solution D: Amend atom:link to do it as follows (in this case @type is  
the type AFTER the transformation, or you'd have to add yet another  
attribute like target-type="..."):
	<link href="..." type="..." stylesheet="..." title="..." />

The question is, how important is it to support this in the core?   
Should atom:link be burdened with this?  Should some other core element  
handle it?  Should Atom clients be expected to be able to perform XSLT  
translations?  Or should transformations be left to an extension, or to  
external resources that do transformations?  Individual applications  
that support XSLT could allow their users to specify stylesheets for  
transforming documents between particular formats (and could come with  
a few built in stylesheets).  Note in Google how, when a PDF document  
comes up in a search, they give you a "View as HTML" link.  The app  
could present a UI for following a link as it is, or converting it to a  
supported format.

 From my perspective, this doesn't seem like something that atom:link  
should be burdened with, and it may not even belong in the core at all.

> What do you think a typical client might display, and what behaviour

Leave that to a different element, al la RSS 2.0's "category" element:

<category domain="http://www.flickr.com">  
http://www.flickr.com/photos/tags/kitten/</category>

---

From: Dare Obasanjo <[email-masked]>
Date: Wed, 20 Oct 2004 09:18:14 -0700 (PDT)

> What do you think a typical client might display,

I don't see why you'd want to express that with a
<link> element despite whatever inconsistent
brokenness exists in HTML today. 

> What do you think a typical client might display,

I agree with Antone and Robert, use some other element
for this not <link>. 

=====