Subject: Work Queue Rotation #13

From: Tim Bray <[email-masked]>
Date: Mon, 22 Nov 2004 13:10:48 -0800

Current issues list: 
http://www.intertwingly.net/wiki/pie/AtomPubIssuesList

Volume has been high, and it's possible I missed something or got it 
wrong: push back as appropriate.

PaceLinkPurpose, which is closed, wants to replace the description of 
the language describing <link>.  There's a proposal from Rob Sayre to 
replace it, at http://imc.org/atom-syntax/mail-archive/msg11584.html - 
that proposal got some cheers and no significant pushback; I'm inclined 
to skip over the Pace process and declare Sayre's proposal to have 
rough consensus.  If anyone disagrees, Rob has to write a Pace.

PaceConstructAttribute, PaceRelationshipConstruct:
* -1 from Bray, Sayre
** Mark it for closure

PaceFieldingLinks:
* Some positive comments, no -1's
* Calls for ruling out relative URIs (done)
* Calls for wording change from Graham based on Cocoa code examples 
didn't get much support.
* Outstanding calls for language about how rel= values are to be 
compared.  A Pace needs to be written if someone cares enough
* Agreement that if there's consensus on some more rel= values for the 
initial revenue, we should get them in to the format draft, go ahead 
and write Paces.
** I believe this has rough consensus and should be accepted.

PaceHeadInEntry
* Discussion on how inheritance works.  Clearest statement from Wyman: 
http://imc.org/atom-syntax/mail-archive/msg11683.html
* Seems to me that this implies removing atom:origin.  Does anyone 
disagree?
* Suggestion from Underwood that the potentially-misleading word 
"inherit" not be used
* Should be first child: 
http://imc.org/atom-syntax/mail-archive/msg11627.html
** I'm inclined to say this has rough consensus; will need some 
application of editorial judgment.

 From here on down, the *only* comments were from me:

PaceLinkByLocation
* One -0, no cheerleaders
** Close it

PaceLinkRelPrefixReg
* One -0, no cheerleaders
** Close it

PaceMetaElement
* One -1, no cheerleaders
** Close it

  -Tim

---

From: Bjoern Hoehrmann <[email-masked]>
Date: Tue, 23 Nov 2004 05:26:40 +0100

>rough consensus.  If anyone disagrees, Rob has to write a Pace.

The proposal makes little sense to me, in particular I do not understand
the difference to "HTML dialects" that is suggested here, so I am -1 to
have this text in the draft.

>* Some positive comments, no -1's

I am clearly -1 on this as I've indicated earlier as this base URI stuff
makes no sense.

>compared.  A Pace needs to be written if someone cares enough

Sorry but the Pace is clearly incomplete without this.

---

From: Henry Story <[email-masked]>
Date: Tue, 23 Nov 2004 09:10:37 +0100

It seems to me that PaceEntriesAllTheWayDown2 with atom:origin is a 
good counter proposal to PaceHeadInEntry. It also simplifies the spec a 
lot more. The two should at least be compared and evalutated on their 
merit.

It may not be obvious from the discussion but I would see the following 
people to have
at least been interested by the idea:
	+ Robert Sayre who proposed PaceEntriesAllTheWayDown, the previous 
version
	+ Antone Roundy, who has proposed criticism for the proposal, but none 
of which seems definitively to bury it. They are more like enunciations 
of the consequences of the proposal

Henry

---

From: Danny Ayers <[email-masked]>
Date: Tue, 23 Nov 2004 12:38:59 +0100

Thanks Tim. 

The parts highlighted by Bjoern and Henry do seem the pieces that are
less clear-cut.

I appreciate Rob's effort to try and get some usable wording, but to
me the suggested version (pasted below) seems too far removed from the
world of resources and HTTP, also overly prescriptive. I don't think
it needs a Pace, but does need revisiting.

I *tried* to follow the threads about
PaceHeadInEntry/PaceEntriesAllTheWayDown2 but to be honest got
completely lost in not only the practical implications but also the
motivation for each approach. Before I personally would be able to
judge one way or the other I'd need a copy of "Head For Dummies".

Cheers,
Danny.

[[
A Link construct is an empty element that describes a connection from
an Atom document to another Web resource. When a link is activated,
User Agents are expected to visit the linked resource, rather than
apply metadata such as schema or styling information as is common in
HTML dialects.
]]

-- 

http://dannyayers.com

---

From: Martin Duerst <[email-masked]>
Date: Tue, 23 Nov 2004 22:34:31 +0900

>I am clearly -1 on this as I've indicated earlier as this base URI stuff

"makes no sense" isn't a technical argument. "it doesn't work" or
"here is something better" is much better. I think Roy has expressed
the reasons for this proposal best, but I'll summarise them here:

- central registry for well-used stuff so that it can be found, and
   doesn't need to be duplicated, and can be expressed in a short form
- Ability for a very wide range of people to create their own values
   ad-hoc if they need them, without collision (as long as the rules are
   followed)
- Overall common space for these values, and clear mapping to technologies
   such as RDF.

 >Sorry but the Pace is clearly incomplete without this.

I agree that the comparison text should go into PaceFieldingLinks
itself, and should be rather easy to write.

Regards,    Martin.

---

From: Robert Sayre <[email-masked]>
Date: Tue, 23 Nov 2004 09:39:50 -0500

> it needs a Pace, but does need revisiting.

Too far removed from a requirement that isn't present, vague, and yet 
still overly precriptive. I've really accomplished something here.

However, I find your objection insufficiently detailed. Show us a use 
case and a problem with the language in concrete terms.

Robert Sayre

---

From: Henry Story <[email-masked]>
Date: Tue, 23 Nov 2004 16:04:27 +0100

Let me summarize PaceEntriesAllTheWayDown2.

Some time ago, black folks in america were treated one way, differently 
from white folks. Laws for each group were different, because they were 
thought to be two different types of people. After a lot of fighting 
and hard work, it was seen that there was no need for the law to make 
any distinctions between the two groups. The law, it was seen would be 
simpler and more just if it treated all as equal.

Similarly I am saying that the structure that goes in the "head", is 
really no different from the Entry structure. The distinctions that are 
being made between entry metadata and feed metadata, all seem 
superfluous to me. We loose nothing by scratching them, and we gain a 
lot of simplicity in the spec and in our understanding of what we are 
doing.

Anotone Roundy made a nice side by side comparison of the current 
differences between
what goes in a head and what goes in an Entry [1]. I responded to some 
of the questions he asked [2]. In his response to this message [3] 
Antone agreed that MOST of the structural difference can be resolved. 
Perhaps with a little effort we will find that all of it can be, or if 
not that an elegant solution exists that takes into account this 
overwhelming similarity.

Henry Story

[1] http://www.imc.org/atom-syntax/mail-archive/msg11577.html
[2] http://www.imc.org/atom-syntax/mail-archive/msg11604.html
[3] http://www.imc.org/atom-syntax/mail-archive/msg11673.html

---

From: Antone Roundy <[email-masked]>
Date: Tue, 23 Nov 2004 08:09:26 -0700

> ** I believe this has rough consensus and should be accepted.
I'm strongly in favor of accepting this, and writing a Pace to cover 
comparison of @rel values.  Let's make progress a little at a time 
rather than holding back on ANY progress until we've got it perfect.  
We've been doing that in some areas for long enough.

> application of editorial judgment.
+1.  Again, if there are details that need adjustment, let's accept 
this first and adjust afterward.

---

From: Antone Roundy <[email-masked]>
Date: Tue, 23 Nov 2004 08:15:53 -0700

> have this text in the draft.
The difference is that we (at least some of us) don't want atom:link 
used for things like this:

<link rel="stylesheet" type="text/css" href="/stylesheets/menu.css">

We want it used only for links that are meant to be activated by the 
user and result in visiting the resource.

---

From: Joe Gregorio <[email-masked]>
Date: Tue, 23 Nov 2004 10:45:27 -0500

> We've been doing that in some areas for long enough.

+1 on the accepting the Pace as is and  a big +1 to the 
sentiment of making progress a little 
at a time rather than holding back ANY progress until 
something is perfect. 

    -joe

-- 
Joe Gregorio        http://bitworking.org

---

From: Bjoern Hoehrmann <[email-masked]>
Date: Tue, 23 Nov 2004 16:57:04 +0100

>   ad-hoc if they need them, without collision (as long as the rules are

When Tim asked not to discuss syntax and rather how to proceed and Roy
proposed this syntax, Tim already mentioned using URIs for extensions
here, so this is nothing new or unique to Roy's proposal.

>- Overall common space for these values, and clear mapping to technologies

That does not seem worth the additional complexity, we do not map other
attribute values into "URI space" either, so why would we do this here?

---

From: Bjoern Hoehrmann <[email-masked]>
Date: Tue, 23 Nov 2004 16:58:37 +0100

>user and result in visiting the resource.

I don't think the HTML 4.01 Recommendations considers this "link"
activated when the style sheet is applied to the document, though
the question is quite interesting.

---

From: Henry Story <[email-masked]>
Date: Tue, 23 Nov 2004 17:19:13 +0100

Thinking about this a little more I don't think I need to stop the 
PaceHeadInEntry.
PaceEntriesAllTheWayDown2 seems to me to be compatible with it, though 
from my current understand, perhaps just a little unnecessary.

Henry

On 23 Nov 2004, at 16:04, Henry Story wrote:

> Some time ago, black folks in america were treated one way, 
> differently from white folks. Laws for each group were different, 
> because they were thought to be two different types of people. After a 
> lot of fighting and hard work, it was seen that there was no need for 
> the law to make any distinctions between the two groups. The law, it 
> was seen would be simpler and more just if it treated all as equal.
>
> really no different from the Entry structure. The distinctions that 
> are being made between entry metadata and feed metadata, all seem

---

From: Danny Ayers <[email-masked]>
Date: Tue, 23 Nov 2004 19:07:04 +0100

> case and a problem with the language in concrete terms.

"A Link construct is an empty element that describes a connection from
an Atom document to another Web resource." 

Ok. Why not just leave it at that. 
Let me try to disambiguate the next bit to show why I don't think it works -

"When a link is activated, User Agents are expected to visit the
linked resource, rather than
apply metadata such as schema or styling information as is common in
HTML dialects."
=>
 "The User Agent will present the user with some form of interface
component corresponding to the link construct through which they may
interact (such as a hyperlink or button). The User Agent is expected
to respond to interactions with that component by applying a HTTP GET
to the resource identified by the URI and somehow processing the
returned data. The construct should not be interpreted as a
declarative statement of a relation between the Atom document and the
identified resource, nor should the data returned by the GET be used
for validation or display styling purposes."

Why not just take the first sentence, and leave it to the definition
of the 'rel' to explain the nature of the connection? What's wrong
with purely declarative (non-hyperlink) connections?

If a hyperlink really *is* all that's intended, then why not just say
something like: "the <link> element describes a hyperlink which the
User Agent is expected to treat link a HTML anchor tag, providing HTTP
access to the identified resource".

Cheers,
Danny.

-- 

http://dannyayers.com

---

From: Antone Roundy <[email-masked]>
Date: Tue, 23 Nov 2004 11:59:04 -0700

> Ok. Why not just leave it at that.
Because it doesn't rule out substantially different uses that people 
might (and in fact have) come up with for <link> which make generic 
link processing impossible.

> interact (such as a hyperlink or button).
Okay.
> The User Agent is expected
> returned data.
Only if the URI is an HTTP URI.

> The construct should not be interpreted as a
> identified resource
Either I don't understand what you mean, or I disagree.  The @rel value 
does describe the relationship between the resources--one's an 
alternative format version of the other, they're related (ie., talk 
about the same topic), one is a response to the other, etc.

> nor should the data returned by the GET be used
Okay.

> with purely declarative (non-hyperlink) connections?
Nothing, as long as they're in a different element.  Lumping them into 
the same element as hyperlinks would make it impossible to use generic 
processing on the <link> element.

What reason is there for using the same element for both hyperlinks and 
non-hyperlink ... links?

> access to the identified resource".
* <nit-pick>I think the term "hyperlink" describes a subset of ways 
that a feed reader might render <link> elements.</nit-pick>

* <atom:link> is different in various ways from <html:a> (for example, 
we never use <link name="foo" /> to create the target endpoint of a 
link), so defining atom:link in terms of html:a is imprecise at best.

* The protocol specified by the link may not be HTTP.

> apply metadata such as schema or styling information as is common in
This text does not get into specifics which won't apply in all 
circumstances.  The reference to HTML is just an example for 
clarification in terms familiar to many who will read the spec.  It 
strikes me as an excellent minimalist way of describing the desired 
limitation to the scope of the <link> element.

---

From: Danny Ayers <[email-masked]>
Date: Tue, 23 Nov 2004 20:36:26 +0100

> Only if the URI is an HTTP URI.

Ok, I completely missed non-HTTP URIs.

> about the same topic), one is a response to the other, etc.

Ok, what I should have said is "The construct should not be
interpreted as *only* a declarative statement...".

> What reason is there for using the same element for both hyperlinks and

Sounds reasonable. I do think there are use cases for expressing
non-hyperlink relationships, such as to a stylesheet or schema, and
for arbitrary declarative relationships. The former are obviously
crying out for elements of their own, the latter should (IMHO) be
covered by the extension mechanism.

> that a feed reader might render <link> elements.</nit-pick>

<nit-pick++> It *is* a hyperlink, how it is rendered is another matter.

> link), so defining atom:link in terms of html:a is imprecise at best.

Sure, perhaps there's some stealable spec wording used for <a
href="..."> somewhere.

It may be useful for informative description somewhere, but it strikes
me as being incredibly woolly -  what does "activated" mean? What does
"visit" mean? What does "apply metadata" mean?

Cheers,
Danny.

-- 

http://dannyayers.com

---

From: Tim Bray <[email-masked]>
Date: Tue, 23 Nov 2004 13:44:48 -0800

On Nov 22, 2004, at 8:26 PM, Bjoern Hoehrmann wrote:

> The proposal makes little sense to me

OK, it's clear that the trial balloon does not enjoy consensus.  Those 
who are unhappy with the <link> language in the draft need to gather 
consensus on changed text; the best way to do that is with a Pace. -Tim

---

From: Asbjørn Ulsberg <[email-masked]>
Date: Thu, 25 Nov 2004 08:39:47 +0100

> ** I believe this has rough consensus and should be accepted.

+1. If this proves to be a really bad idea (which I don't think it will),  
we have at least tried an extension mechanism for links. As it stands now,  
we haven't yet tried anything, simply because everyone doesn't agree on  
one single mechanism. Let's try this one out first, and if it proves to be  
as stupid as base jumping without a parachute, we'll have to come up with  
something better.

I have been thinking, though, that what the idea is almost equal to, is a  
default attribute. I thought of this when I read the category proposals;  
particularly the @scheme attribute. We could say that all links have a  
default @scheme attribute with the value of  
'http://www.iana.org/assignments/relation/'.

Moving the default URI into an attribute gives a clearer separation of how  
to parse the construct, but might obfuscate things. Using 'xml:base' could  
probably work better, but I haven't really thought very hard about it.  
Just my two cents.

> application of editorial judgment.

Fine with me.

> ** Close it

No problem for me.

-- 
Asbjørn Ulsberg     -=|=-    http://virtuelvis.com/quark/
«He's a loathsome offensive brute, yet I can't look away»