Subject: PaceReplaceLinkElement created

From: Graham <[email-masked]>
Date: Fri, 16 Jul 2004 13:06:29 -0400

(it might be helpful to add this to today's issues list)

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

Abstract

  Replace the link element with several different elements, named for 
the various proposed link@rel values.

Status

  Open

Rationale

  Semantically-different link constructs are currently distinguished by 
an attribute named "rel", inherited  from the HTML link construct. This 
causes many problems:
	1. No extension mechanism
	2. Inconsistent with Date, Person and Content constructs, which all 
distinguish semantics using the element name.
	3. Typing based on attribute value is bad practice 

whole approach of "bottom-typing"... leaves a strongly-typed guy like 
me with the whillies

Proposal

Remove:

  3.4.1 "rel" Attribute
  The "rel" attribute indicates the type of relationship that the link

  represents. Link constructs MUST have a rel attribute, whose value 
MUST be a string, and MUST be one of the values enumerated in the Atom 
Protocol specification [Atom-protocol].

  Replace 4.4 "atom:link" Element with sections detailing rel values 
defined in atom-protocol-00 3.4.1. For example:

  atom:alternate

The "atom:alternate" element is a Link construct that points to an 
alternate representation of the containing resource.

  atom:feed elements MUST contain at least one atom:alternate element. 
atom:feed elements MUST NOT contain more than one atom:alternate 
element that has the same type attribute value.

  Replace 4.13.2 "atom:link" Element with a similar list, eg:

  atom:alternate

The "atom:alternate" element is a Link construct that points to an 
alternate representation of the containing resource.

  atom:entry elements MUST contain at least one atom:alternate element. 
atom:entry elements MUST NOT contain more than one atom:alternate 
element that has the same type attribute value.

  Impacts

Some other proposals (eg PaceLinkPurpose) will no longer be relevant. 
There will not be a defined way to extract all Link Constructs from 
atom document.

  Notes

Currently the meanings of the link@rel values are not currently 
defined, thus it was not possible to include within the proposal spec 
text for each of the new elements created by the proposal.

---

From: Tim Bray <[email-masked]>
Date: Fri, 16 Jul 2004 10:25:47 -0700

> the various proposed link@rel values.

Couldn't you do this and still make link-ish elements recognizable by 
insisting on the use of the href= attribute, and only the href= 
attribute in all these descendents of <link? -Tim

---

From: Sam Ruby <[email-masked]>
Date: Fri, 16 Jul 2004 13:37:32 -0400

> http://www.intertwingly.net/wiki/pie/PaceReplaceLinkElement

Added.

>  Replace 4.13.2 "atom:link" Element with a similar list, eg:

My experience is that the devil's in the details, and by not spelling 
out the details, it makes it hard to spot potential problem areas.

Meanwhile, an extensibility question.  If somebody wants to define a new 
element, in a new namespace, are we supposed to wantonly assume that any 
attribute spelled "href" is an indication that an atom LinkConstruct is 
what is intended?

- Sam Ruby

---

From: Graham <[email-masked]>
Date: Fri, 16 Jul 2004 13:59:36 -0400

> out the details, it makes it hard to spot potential problem areas.

That's the best I could do. The various rel values are not properly 
defined yet.

> Meanwhile, an extensibility question.  If somebody wants to define a 
> new element, in a new namespace, are we supposed to wantonly assume 
> that any attribute spelled "href" is an indication that an atom 
> LinkConstruct is what is intended?

I personally don't understand why there is such desperate need to 
recognize extension link constructs.

(because it is only extensions that the current link syntax* helps 
with. A dumb aggregator can still find all of the core links by name)

Graham

(* not that the current link syntax has any viable extension mechanism)

---

From: Tim Bray <[email-masked]>
Date: Fri, 16 Jul 2004 11:09:22 -0700

> LinkConstruct is what is intended?

It's kind of a hack, but also kind of plausible; I'm not sure that 
"wantonly" is the appropriate word. -Tim

---

From: Antone Roundy <[email-masked]>
Date: Fri, 16 Jul 2004 12:13:11 -0600

On Friday, July 16, 2004, at 11:06  AM, Graham wrote:
> an attribute named "rel", inherited  from the HTML link construct. 
> This causes many problems:
Just to make sure we're clear, by "Semantically-different link 
constructs", are you referring to something like the fact that some 
link constructs point to places where a person might send their feed 
reader or web browser next by clicking a link, while others point to 
places their feed editor might post (not limited to HTTP POST) new or 
updated entries, and still others (proposed but not in the current spec 
draft) point to things that their feed reader or web browser might load 
automatically while rendering the feed in which the <link> appears?  Or 
is there some other distinction between different link constructs 
you're referring to?

If that is what you're meaning, PaceServiceElement proposes a 
replacement element for the @rel values appearing in the current API 
spec which aren't in the first group.

> There will not be a defined way to extract all Link Constructs from 
Portions of PaceLinkPurpose could still be relevant even if the link 
element is replaced (we could still limit what Link Constructs can be 
used for), and as Tim & Sam's responses pointed out, we COULD still 
define a way to extract all Link Constructs.

---

From: Paul Hoffman / IMC <[email-masked]>
Date: Fri, 16 Jul 2004 11:17:36 -0700

>LinkConstruct is what is intended?

We can make that wanton assumption if we say in the spec something to 
the effect of "The use of attributes called 'href' mean that they are 
links to the outside world, and anyone extending Atom should only use 
'href' in a way similar to the items in the core spec."

--Paul Hoffman, Director
--Internet Mail Consortium

---

From: Antone Roundy <[email-masked]>
Date: Fri, 16 Jul 2004 12:19:16 -0600

> LinkConstruct is what is intended?
We'd have to explicitly state that in the spec if we wanted to be able 
to do that--we'd have to forbid extensions from having an href 
attribute in an element that wasn't a Link Construct.  We should 
explore other possible methods for identifying Link Constructs too.  
The first that comes to mind, which I imaging some people will oppose, 
is that all Link Constructs have names beginning with "link-".  For 
example, <link-alternate ... />.  That should be much easier for 
extension writers to live with if they need an element with a URI in 
it.  It would also be somewhat easier to identify.

---

From: Graham <[email-masked]>
Date: Fri, 16 Jul 2004 14:29:21 -0400

On 16 Jul 2004, at 2:13 pm, Antone Roundy wrote:

>>  Semantically-different link constructs are currently distinguished 
>> by an attribute named "rel", inherited  from the HTML link construct. 
> updated entries, and still others (proposed but not in the current 
> spec draft) point to things that their feed reader or web browser 
> might load automatically while rendering the feed in which the <link> 
> appears?  Or is there some other distinction between different link 
> constructs you're referring to?

By semantically different I mean they have different @rel values, 
nothing deeper.

Graham

---

From: Graham <[email-masked]>
Date: Fri, 16 Jul 2004 14:41:05 -0400

On 16 Jul 2004, at 2:19 pm, Antone Roundy wrote:

> We should explore other possible methods for identifying Link 
> Constructs too.

Before we can even discuss the appropriate syntax for link, we need a 
sensible answer to this question:

  Why do we need any method for identifying extension Link Constructs?

(I've decided I want a mechanism for identifying all Date constructs, 
core and extension, from any Atom document. I will protest and break 
consensus on any spec that doesn't have one)

Graham

---

From: Robert Sayre <[email-masked]>
Date: Fri, 16 Jul 2004 14:56:47 -0400

> 'href' in a way similar to the items in the core spec."

Or we could define an "extension namespace". That way, the Atom namespace
could remain the un-prefixed default, and the @href would still be in a
namespace.

<feed xmlns="http://purl.org/atom/ns#"
      xmlns:exatom="http://example.com/atom/ex/ns#"
      xmlns:mylink="http://example.com/mylink/ns#"
      version="draft-00 do not implement">
<title>dive into mark</title>
<link href="http://diveintomark.org/" rel="alternate" type="text/html" />
<mylink:specialLink exatom:href="http://google.com"
                    exatom:rel="alternate"
                    exatom:title="Demo" />
...
</feed>

Robert Sayre

---

From: Sam Ruby <[email-masked]>
Date: Fri, 16 Jul 2004 15:27:18 -0400

> That's the best I could do. The various rel values are not properly 

There is a starter set here:

http://bitworking.org/projects/atom/draft-ietf-atompub-protocol-00.html#rfc.section.3.4.1

And a more comprehensive list here:

http://intertwingly.net/wiki/pie/LinkTagMeaning

The question that needs pondering is whether we want a format and/or 
protocol with dozens of elements in the core?  Is fewer elements (one 
perhaps with dozens of options) somehow more "approachable"?

My overall feeling (subjective, I know) is that the latter has 
considerably more "curb appeal".

- Sam Ruby

---

From: Paul Hoffman / IMC <[email-masked]>
Date: Fri, 16 Jul 2004 12:59:18 -0700

At 3:27 PM -0400 7/16/04, Sam Ruby wrote:
>protocol with dozens of elements in the core?  Is fewer elements 
>(one perhaps with dozens of options) somehow more "approachable"?
>

-.5. Folks who code in Perl often find that having one object whose 
semantics change based on the arguments is much easier to flub on 
than lots of objects whose names are syntactically different. From a 
higher level, the fact that this element is a link is not nearly as 
descriptive as the fact that this item is a cross-reference, a 
picture, and so on.

--Paul Hoffman, Director

---

From: Graham <[email-masked]>
Date: Fri, 16 Jul 2004 16:18:34 -0400

> -00.html#rfc.section.3.4.1

I've done what I can with that. It's very thin material to work from  
though. No idea about cardinality rules for any of them.

> http://intertwingly.net/wiki/pie/LinkTagMeaning

Introducing those into the spec belongs in a separate thread,

> perhaps with dozens of options) somehow more "approachable"?

But they are elements! By pretending they're not, all we've done is  
introduce massively under-specified metadata into the spec. If you want  
fewer elements, you need to ditch some rel values.

(and anyway, you could achieve the same effect be tabulating the Link  
construct-based elements)

> considerably more "curb appeal".

Which justifies the shoddiness?

Graham

---

From: Bill de hÓra <[email-masked]>
Date: Fri, 16 Jul 2004 21:22:27 +0100

> By semantically different I mean they have different @rel values, 

I'll push on this a bit. Semantically /different/ to me as a
/concern/, here, would mean there are disjoint types for @rel - ie
there's no code sharing across them and you probably wouldn't have
much joy say hacking a superclass or an @rel visitor. That would
suggest that these things are not all links, for some definition of
link and if so, that it is likely to be the case that we do have
already a problem vis-a-vis the @rel abuse.

cheers
Bill

---

From: Ken MacLeod <[email-masked]>
Date: 16 Jul 2004 15:39:59 -0500

> considerably more "curb appeal".

So much curb appeal that someone thought to introduce a "link" element
for RDF, which is by definition a linking language!

I see one of the principle driving forces for moving the "relation
name" to the element type name is to reuse the existing XML
extensibility structure of XML Namespaces.  For example, we're not
using meta/@rel for all of our other metadata elements, but are using
link/@rel for link elements.

Off-hand, I recall seeing all of the following for extensibility
suggestion for use within @rel:

 * rel="fixed"

   Fixed set of relation names, not extensible except through future
   RFCs that update the list.

 * rel="any"

   Unregistered extensions.

 * rel="registered"

   IANA registered relation names.

 * rel="registered.any"

   IANA registered prefixes, prefix-authority specs names.

 * rel="unregistered.any" or rel="unregistered-any"

   Unregistered prefixes, prefix "owner" specs names.  Used by CSS
   implementors, for example.

 * rel="qname"

   XML qnames in content.

 * rel="http://example.org/relations/any"

   Full URI.

 * rel="schema.any"

   "Link namespaces", per RFC 2731, Encoding Dublin Core Metadata in HTML.

Note that the "relation type" (hyperlink, Atom protocol, embedded) is
not part of the @rel "relation name".  Some of the Paces are
suggesting using a small few new element names to indicate "relation
type" (<link>, <service>), while still using an @rel (or equivalent)
for the relation name.

  -- Ken

---

From: Sam Ruby <[email-masked]>
Date: Fri, 16 Jul 2004 17:03:13 -0400

Paul Hoffman / IMC wrote:

> semantics change based on the arguments is much easier to flub on than 
> lots of objects whose names are syntactically different. From a higher 
> level, the fact that this element is a link is not nearly as descriptive 
> as the fact that this item is a cross-reference, a picture, and so on.

FWIW, the motivation wasn't Perl, it was HTML:

http://www.w3.org/TR/REC-html40/struct/links.html#h-12.3
http://www.w3.org/TR/REC-html40/types.html#type-links

When one has an archive, one can imagine a start, next, and prev, 
contents, etc, exactly like HTML.

Furthermore, all blogs should have a <link rel="alternate"> to their 
feed(s), so a symmetric backlink seemed appropriate.

- Sam Ruby

---

From: Ken MacLeod <[email-masked]>
Date: 16 Jul 2004 19:14:23 -0500

Paul Hoffman / IMC <[email-masked]> writes:

> > The question that needs pondering is whether we want a format
> > and/or protocol with dozens of elements in the core?  Is fewer
> > elements (one perhaps with dozens of options) somehow more
> > "approachable"?
> >

If I read this right, you're thinking that each link would be a
different class (module) because it's name is different?  I don't
think that's the case, child elements of "entity constructs" like
atom:feed and atom:entry are typically mapped to object attribute
names, not object types.  $entry->{alternate} has all the 'alternate'
links of that entry, of which each is an instance of the Atom::Link
class (because elsewhere in the spec we've said how to know an element
is a link).

  -- Ken

---

From: Eric Scheid <[email-masked]>
Date: Sat, 17 Jul 2004 13:10:20 +1000

> 'href' in a way similar to the items in the core spec."

-1 to this meme.

Some other xml vocab could say something different (eg. href is used for
transclusion), and thus someone writing a context-agnostic extension (eg.
<geo>) would be screwed. (examples are not normative!)

I wouldn't be surprised if there isn't some extension module already written
which would now be incompatible with atom. That would be our loss, imho.

e.

---

From: Joe Gregorio <[email-masked]>
Date: Fri, 16 Jul 2004 23:32:25 -0400

> attribute spelled "href" is an indication that an atom LinkConstruct is

For this reason I would prefer this attribute be atom:href.

    -joe

---

From: Dave Pawson <[email-masked]>
Date: Sat, 17 Jul 2004 08:46:15 +0100

> For this reason I would prefer this attribute be atom:href.

-1 to 'assuming semantics' from an attribute name.
It just doesn't make sense to me.

Define a link in the spec, syntax and semantics, if the
element+attribute combination doesn't meet the spec 
then its something else, not a link. 

-- 
Regards DaveP.
XSLT&Docbook  FAQ
http://www.dpawson.co.uk/xsl

---

From: Bill de hÓra <[email-masked]>
Date: Sat, 17 Jul 2004 12:49:13 +0100

>>'href' in a way similar to the items in the core spec."

I must be missing something. If we want to allow folks to put the 
href with our semantics on their elements, why aren't we specifying 
@atom:href?

cheers
Bill