Subject: PaceLinkRelMechanism

From: Dare Obasanjo <[email-masked]>
Date: Fri, 8 Oct 2004 10:38:42 -0700 (PDT)

-1 on this Pace. As it is the values of the rel
attribute do not have uniform semantics so there is no
way for a client to consume a link element with a rel
value it doesn't understand and have it do anything
reasonable with it. 

This Pace basically looks like a way to create an
extension mechanism that duplicates the ability to use
extension elements. This redundancy alone is worth the
-1. 

=====
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: Danny Ayers <[email-masked]>
Date: Fri, 8 Oct 2004 20:05:42 +0200

+1 to the Pace.

As one of the original proponents of this Pace, I stand by the
original aim - to provide some form of extensibility that has tighter
constraints than 'anything in another namespace can go anywhere'.  I
haven't seen any other proposals that offer this in a better form.

If there is no clear consensus on this I would suggest it be revisited
with the extensible form of the rel attribute reduced to a simple URI.

> value it doesn't understand and have it do anything

Uniform semantics are defined in the Pace (under 'Proposal').

> extension elements. This redundancy alone is worth the

If by "extension elements" you mean elements from other namespaces
that can go anywhere, this has been discussed before. The only
redundancy is comparable to the pattern "microsoft.com" being
redundant when you have the expression "*".

Cheers,
Danny. 

-- 

http://dannyayers.com

---

From: Graham <[email-masked]>
Date: Fri, 8 Oct 2004 19:20:28 +0100

Big -1 too. No one will implement this.

Graham

On 8 Oct 2004, at 6:38 pm, Dare Obasanjo wrote:

> 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.
>
>
>

---

From: Danny Ayers <[email-masked]>
Date: Fri, 8 Oct 2004 20:35:11 +0200

Implement what?

Tools that only use the core definitions would check the value of any
rel attribute against the rel list, exactly as they would have to in
current circumstances. The only real difference would be the absence
of an error message in a validator that checked the enuration.

On the other hand, if you want to use the link element to associated
an item with something shall we say like an mp3 file, then it's easily
done.

Cheers,
Danny.

-- 

http://dannyayers.com

---

From: Graham <[email-masked]>
Date: Fri, 8 Oct 2004 19:42:07 +0100

If we end up going with it people will key off the QNames.

I've just read the proposal properly and noticed it reuses the same 
prefixes as the XML namespaces. Yuck. Whoever wrote this crap needs to 
read up on abstraction and separation between processing layers.

Graham

---

From: Antone Roundy <[email-masked]>
Date: Fri, 8 Oct 2004 12:50:44 -0600

> haven't seen any other proposals that offer this in a better form.
-1.  I'd prefer a method where the @rel value is entirely self 
contained, rather than referring to a namespace or schema whose prefix 
is associated with its URI (or whatever) elsewhere in the document.  To 
avoid potential collisions, making it self contained would require one 
of: a) the use of URIs in @rel, b) registration of all @rel values or 
3) my preference[1]: registration of a prefix, but not of every value 
(similar to MIME's prs and vnd subtypes).  If this idea is not quickly 
trounced, I'll write a proposal.

[1] http://www.imc.org/atom-syntax/mail-archive/msg09857.html -- #5

---

From: Danny Ayers <[email-masked]>
Date: Fri, 8 Oct 2004 20:56:18 +0200

On Fri, 8 Oct 2004 19:42:07 +0100, Graham <[email-masked]> wrote:
> prefixes as the XML namespaces. Yuck. 

You will then have noticed Norm's remark - "The announcement that the
next version of HTML is going to use QNames in rel puts this question
to bed, I think. Using anything else in Atom would be hard to defend."

I am aware this may be a bone of contention, which is why I suggested
a possible future amendment to the proposal (to use full URIs) in my
previous post.

Whoever wrote this crap needs to
> read up on abstraction and separation between processing layers.

Perhaps you should read up on WG etiquette.

Cheers,
Danny.

-- 

http://dannyayers.com

---

From: Dare Obasanjo <[email-masked]>
Date: Fri, 8 Oct 2004 12:21:56 -0700 (PDT)

> to bed, I think. Using anything else in Atom would

Having QNames in content causes a ridiculous amount of
problems in XML processing. It's unfortunate that we
are stuck with them in core XML technologies like XSLT
and W3C XML Schema but it doesn't mean this should be
allowed to spread unchecked in the XML world. 

Even the W3C TAG frowns on the practice but admits the
cat is already out of the bag 

  http://www.w3.org/2001/tag/doc/qnameids.html

=====

---

From: Tim Bray <[email-masked]>
Date: Fri, 08 Oct 2004 13:40:44 -0700

> to bed, I think. Using anything else in Atom would be hard to defend."

Without taking any position on the underlying issue, but noting with 
pleasure the lively debate, I'd like to say that as far as I'm 
concerned, what the designers of the in-progress, unstable, 
violently-controversial next version of HTML are deciding to do is of 
approximately zero significance to our design decisions for Atom.  -Tim

---

From: Tim Bray <[email-masked]>
Date: Fri, 08 Oct 2004 13:44:20 -0700

> allowed to spread unchecked in the XML world.

+1 -Tim

---

From: Danny Ayers <[email-masked]>
Date: Sat, 9 Oct 2004 00:11:30 +0200

> approximately zero significance to our design decisions for Atom.  -Tim

Please allow me to be contrary. I'll declare my position on the
underlying issue - I think QNames in attributes are generally a bad
idea. But they are in use in other XML formats, and they may offer a
pragmatic solution to some problems. Their use in places like XSLT are
of little consequence to Atom. But the next version of HTML is at
least a potential format for Atom payloads. I could be missing
something, but if the content of an Atom feed is (unescaped) XHTML,
and that version of XHTML has QNames in attributes then it seems to me
the document as a whole will have QNames in attributes. The fact that
those attributes won't be in the Atom namespace is only half the
story, the prefix binding may not be inside the content fragment.
Leak, leak. What responsibility should the carrier format have for
maintaining the association? As with control characters in plain text,
I would suggest that the format of the content probably is of
significance to decisions regarding the delivery format.

Cheers,
Danny.

-- 

http://dannyayers.com

---

From: Eric Scheid <[email-masked]>
Date: Sat, 09 Oct 2004 12:23:31 +1000

> with the extensible form of the rel attribute reduced to a simple URI.

-1 to this pace, and -1 to struggling to find consensus ... I'm not so sure
we really need to try so hard to solve this problem so soon. The theoretical
dangers of @rel collisions are pretty slight.

oh yeah, -1 on using URIs instead of tokens in @rel. It makes the feed even
bulkier, prevents considering the idea of space delimited tokens (+/-), and
raises the horrible question of canonicalisation all over again.

e.

---

From: Antone Roundy <[email-masked]>
Date: Fri, 8 Oct 2004 23:05:08 -0600

On Friday, October 8, 2004, at 12:50  PM, Antone Roundy wrote:
> is associated with its URI (or whatever) elsewhere in the document.  
> To avoid potential collisions, making it self contained would require 
> one of: a) the use of URIs in @rel, b) registration of all @rel values 
> or 3) my preference[1]: registration of a prefix, but not of every 
> value (similar to MIME's prs and vnd subtypes).  If this idea is not 
> quickly trounced, I'll write a proposal.
>
Having heard no objections, and having gotten one off-list +1, I've 
written PaceLinkRelPrefixReg

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

The proposed spec text follows.  I imagine it will have to be altered 
somewhat to clarify where to go to register with IANA[1?]. I assume 
this would go into a new section in the Directory of General Assigned 
Numbers[2]:

3.4.1 rel

This attribute describes the relationship from the current document to 
the anchor
specified by the href attribute. The value of this attribute is a 
space-separated
list of link types. Link Constructs MUST have a rel attribute, whose 
value MUST
be a string, and MAY either be one of the values enumerated below or be 
defined
externally.

Externally defined values MUST begin with a prefix which has been 
registered with
IANA. Only the registrant of the prefix can define values beginning 
with that
prefix. Prefixes and the values that follow them MUST be separated by a 
hyphen,
and both MUST consist entirely of alphanumeric characters.

The value of this attribute is case-insensitive.

[1] http://www.iana.org/cgi-bin/assignments.pl
[2] http://www.iana.org/numbers.html

---

From: Danny Ayers <[email-masked]>
Date: Sat, 9 Oct 2004 12:25:42 +0200

[oops - forgot the cc]

> dangers of @rel collisions are pretty slight.

I don't understand - are you suggesting that @rel should be arbitrary strings?

> bulkier,

I don't think half-a-dozen or so extra chars in a link are a big deal,
especially compared with the restriction of having an ennumerated set
of tokens and/or creating a new token mechanism.

>prevents considering the idea of space delimited tokens (+/-),

I mut have missed that bit - I'm assuming you mean having multiple
tokens in a rel? What's wrong with using spaces? (Are multiple tokens
going to be common enough to justify this option rather than simply
having multiple link elements?)

>and

Not necessarily - it would make sense to use the existing definitions.

Cheers,
Danny.

---

From: Bill de hÓra <[email-masked]>
Date: Sat, 09 Oct 2004 11:26:44 +0100

> to bed, I think. Using anything else in Atom would be hard to defend."

-1 on QName mechanism. I think I said this here once before, but 
that is HTML's problem, not Atom's. Placing QNames in content is 
misguided - not something I would want to see propagated in Atom.

cheers
Bill

---

From: Bill de hÓra <[email-masked]>
Date: Sat, 09 Oct 2004 11:22:22 +0100

> read up on abstraction and separation between processing layers.

Rudeness objection.

cheers
Bill

---

From: Danny Ayers <[email-masked]>
Date: Sat, 9 Oct 2004 12:48:02 +0200

I favour the extensibility, but am not convinced this is a good approach.

Your rationale against URIs is: "Using URIs as @rel values would
result in larger feeds, and would look messier" - neither is exactly a
big deal, see example below. If the URI is well chosen, the only
non-informational characters in it in this context are those of the
scheme.

But having to register namespaces IANA-style significantly raises the
bar to entry, centralizing control and demanding a new mechanism for
interpretation and new  infrastructure to support the registry. That's
all Web -1.0 stuff.

Cheers,
Danny.

<link rel="http://xmlns.com/foaf/0.1/depiction"
        type="image/jpeg"
        href="http://rdfweb.org/people/danbri/2001/09/cam/danbri-vegemite.1000843912.jpg#"
        title="danbri with yeast extract" />

<link rel="vnd.xmlns.foaf.0.1.depiction"
        type="image/jpeg"
        href="http://rdfweb.org/people/danbri/2001/09/cam/danbri-vegemite.1000843912.jpg#"
        title="danbri with yeast extract" />

-- 

http://dannyayers.com

---

From: Graham <[email-masked]>
Date: Sat, 9 Oct 2004 15:37:33 +0100

Motion put to the floor of the house:

There is no practicable way to make @rel values extensible.

Graham

---

From: Antone Roundy <[email-masked]>
Date: Sat, 9 Oct 2004 08:53:24 -0600

On Saturday, October 9, 2004, at 04:48  AM, Danny Ayers wrote:
> big deal
True, not every part of the rationale is as important as the others.  A 
bigger issue with URIs (which I just added to the Pace) is that they 
would raise the issue of canonicalization again.

> bar to entry
...which may or may not not be a bad thing.  Quoting[1] Sam from a 
while back:

"At the moment, I'm leaning towards [snip] establishing a registration 
scheme for new values. Hopefully the registration scheme will be hairy 
enough to scare away fivilous and unproven suggestions. Hmmm, seems to 
me like IANA might fit that bill."

Prefix registration is aimed at falling somewhere between the 
difficulty of registering every value and solutions which require no 
registration at all.

[1] http://www.imc.org/atom-syntax/mail-archive/msg07393.html

---

From: Robert Sayre <[email-masked]>
Date: Sat, 09 Oct 2004 11:22:16 -0400

> There is no practicable way to make @rel values extensible.

Seconded. QNames in attribute values is a bad idea. We will never reach 
consensus to do it.

Why not use atom:href in extension elements?

Get every link in the document like this:

//*[@atom:href]

Robert Sayre

---

From: Bill de hÓra <[email-masked]>
Date: Sat, 09 Oct 2004 16:34:27 +0100

> There is no practicable way to make @rel values extensible.

I agree; it's difficult to stuff an extensiblilty model into an 
attribute. If there is a practical way, it will probably be easier 
for someone to find if we spec the use of URIs.

cheers
Bill

---

From: Dare Obasanjo <[email-masked]>
Date: Sat, 9 Oct 2004 08:38:58 -0700 (PDT)

> Get every link in the document like this:

I don't think anyone has ever complained about the
syntax so your proposed solution does nothing to
change the problem. The problem being, exactly what is
the semantics of a link so consumers of Atom feeds can
know how to process them in a uniform manner. 

=====

__________________________________
Do you Yahoo!?
Yahoo! Mail Address AutoComplete - You start. We finish.
http://promotions.yahoo.com/new_mail

---

From: Antone Roundy <[email-masked]>
Date: Sat, 9 Oct 2004 09:46:54 -0600

On Saturday, October 9, 2004, at 09:22  AM, Robert Sayre wrote:
> Seconded. QNames in attribute values is a bad idea. We will never 
> reach consensus to do it.
>

So any element that contains @atom:href is a Link Construct, with all 
the attributes required of a Link Construct, and no additional 
attributes or child content/elements that need to be understood to be 
able to process it properly?  Or can you not infer that?  If not, then 
the usefulness of this approach is extremely limited.

Of course, I'm not saying I'm entirely opposed to this approach--I did, 
after all, write PaceExtensionNamespace, the core idea of which is 
this.  But I myself have since decided I'd prefer a different approach. 
  One possibility is PaceLinkRelPrefixReg (which does not use QNames in 
attributes), and another is #6 in 
http://www.imc.org/atom-syntax/mail-archive/msg09857.html -- use 
@atom:construct to identify what Atom Construct an extension element 
follows the rules for.  For example,

<myext:mylink atom:construct="link" href="..." title="..." />

If <myext:mylink> becomes popular enough, @atom:construct could 
eventually be dropped from it, since most aggregators would know it was 
a Link Construct without the hint (and in fact, @atom:construct could, 
and probably should, be optional from the beginning).

Once again, if the idea isn't quickly trounced, I'll write a proposal, 
so that we can have something concrete to discuss.

---

From: Danny Ayers <[email-masked]>
Date: Sat, 9 Oct 2004 18:01:45 +0200

> > There is no practicable way to make @rel values extensible.

Why aren't URIs practicable?

> Seconded. QNames in attribute values is a bad idea. We will never reach

Ok. Same question again.

> Get every link in the document like this:

You mean something like: 

<foaf:depiction atom:href="http://example.org/danbri-vegemite.jpg" />

?

That sounds workable, assuming you also had something saying what the
anchor/subject of the link/relationship was (presumably the parent
element) - e.g. if the element above was an immediate child of <entry>
the image would be a depiction of the entry, inside <author> it would
be a depiction of the the author etc.

If this were fleshed out a little I for one would be happy to drop
<link rel...> as an extensibility point.

Cheers,
Danny.

-- 

http://dannyayers.com

---

From: Robert Sayre <[email-masked]>
Date: Sat, 09 Oct 2004 12:16:10 -0400

Dare Obasanjo wrote:

>>>There is no practicable way to make @rel values
>>
>>extensible.
>>
> change the problem.

False. Here on atom-syntax, numerous people have complained about the 
syntax, because it has all the problems of HTML4's link tag.

> The problem being, exactly what is

Here's the definition of a link I like to use:

"A link is a connection from one Web resource to another. Although a 
simple concept, the link has been one of the primary forces driving the 
success of the Web.

The default behavior associated with a link is the retrieval of another 
Web resource."[0]

In other words, if you don't want it retrieved, don't put it in a link. 
Other information might be associated with the relationship. The class 
of Atom consumers known as aggregators can render unknown links in a 
manner similar to the Mozilla web browser's "Site Navigation Bar", or 
skip them all together.

Robert Sayre

[0] http://www.w3.org/TR/REC-html40/struct/links.html

---

From: Antone Roundy <[email-masked]>
Date: Sat, 9 Oct 2004 10:21:05 -0600

On Saturday, October 9, 2004, at 09:46  AM, Antone Roundy wrote:
> #6 in http://www.imc.org/atom-syntax/mail-archive/msg09857.html -- use 
> eventually be dropped from it, since most aggregators would know it 
> was a Link Construct without the hint (and in fact, @atom:construct 
> could, and probably should, be optional from the beginning).
>

Okay, I had a spare minute, so I went ahead an wrote an indirectly 
competing proposal for the one I wrote yesterday without waiting to be 
trounced.

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

Here's the proposed spec text:

X.X.X. atom:construct attribute

This attribute MAY be used by extension elements to indicate that they 
follow the
rules defined in this specification for some type of Construct. The 
value of this
attribute MUST be one of "link", "date", or "person". The value MUST be 
lowercase.
Elements containing this attribute MUST include all of the attributes 
and child
content required by this specification for the named Construct type. 
They MUST NOT
contain additional attributes or child content which is required in 
order to
process the element in an acceptable manner.

Example: The following indicates that myext:mylink is a Link Construct, 
as defined
by this specification:

<myext:mylink atom:construct="link" rel="my-rel-value" 
href="http://myserver.com/" />

---

From: Danny Ayers <[email-masked]>
Date: Sat, 9 Oct 2004 18:23:51 +0200

On Sat, 9 Oct 2004 08:38:58 -0700 (PDT), Dare Obasanjo <[email-masked]> wrote:
> syntax 

I got the impression the first post in this thread was doing just that.

so your proposed solution does nothing to
> know how to process them in a uniform manner.

That's not difficult -

"The link construct defines a binary relationship between the parent
of the element in which it appears, and the resource identified in the
atom:href attribute. The nature of that relationship is detemined by
the name of the element containing the atom:href attribute. If that
name is in the Atom namespace, then a consumer MUST interpret it and
behave according to the definition of that term in this specification.
Otherwise the consumer MAY follow whatever definition is provided for
the the term in the namespace in question. If the consumer has no
knowledge of the term then it MAY ignore it or present the data to the
end user in any manner deemed appropriate".

Examples (something like):

<atom:entry>
   <atom:id>http://example.org/blah</atom:id>
   <atom:service atom:method="edit" atom:href="http://example.org/editme" />
...
</atom:entry>

This says: the edit endpoint using the Atom Protocol for the resource
http://example.org/blah is http://example.org/editme.

<atom:entry>
   <atom:id>http://example.org/blah</atom:id>
   <foaf:depiction atom:href="http://example.org/veg.jpg" />
...
</atom:entry>

This says: http://example.org/veg.jgp is a foaf:Image which depicts
the resource http://example.org/blah

Cheers,
Danny.

-- 

http://dannyayers.com

---

From: Danny Ayers <[email-masked]>
Date: Sat, 9 Oct 2004 18:30:08 +0200

> The default behavior associated with a link is the retrieval of another

I've no objection whatsoever to the <link> element being defined in
this way, as long as there is still a uniform means of defining
arbitrary relationships between Atom resources and other resources.
This could be provided by Paul's mechanism (replace 'link construct'
with 'relationship construct' in the definition I offered).

This might just give us the best of both worlds.

Cheers,
Danny.

-- 

http://dannyayers.com

---

From: Danny Ayers <[email-masked]>
Date: Sat, 9 Oct 2004 18:33:11 +0200

Sorry, that should have read "...Robert's mechanism...".

-- 

http://dannyayers.com

---

From: Antone Roundy <[email-masked]>
Date: Sat, 9 Oct 2004 10:47:52 -0600

On Saturday, October 9, 2004, at 10:16  AM, Robert Sayre wrote:
> The default behavior associated with a link is the retrieval of 
> another Web resource."[0]
>

I don't think this is quite narrow enough.  I think <link> should be 
used to retrieve a primary resource.  By "primary resource" I mean for 
example, an HTML page.  The HTML page itself may contain pointers to 
stylesheets, images, etc., which will also be retrieved, but which, in 
that context, are not the primary resources.  That's not to say that 
those other resources couldn't, in some other context, be primary 
resources.  In such a context, it would be appropriate for <link> to 
point to them.

---

From: Robert Sayre <[email-masked]>
Date: Sat, 09 Oct 2004 12:56:32 -0400

> with 'relationship construct' in the definition I offered).

http://infomesh.net/2002/rdfinhtml/#conclusion

<!-- no need for that tiresome RDF/XML syntax -->
<foo:AssertionsAboutThisEntry atom:href="example.org/rdf.n3" />

We give you a URI to identify a given atom:entry, so there is no need to 
package assertions in the XML, but you could if you wanted gargantuan 
Atom entries.

Robert Sayre

---

From: Robert Sayre <[email-masked]>
Date: Sat, 09 Oct 2004 13:06:17 -0400

> resources.  In such a context, it would be appropriate for <link> to 

Hmmm. I don't think I understand the distinction you are trying to make. 
Perhaps you mean resources that would be the focus of a primary viewing 
window? I don't think requirements on UA behavior are in-bounds here.[0]

UAs can make that decision based on type attributes, HEAD requests, etc.

Robert Sayre

[0] 
http://www.25hoursaday.com/weblog/PermaLink.aspx?guid=d9c0205d-3cc1-4efb-a62f-7b0f05fb13af

---

From: Danny Ayers <[email-masked]>
Date: Sat, 9 Oct 2004 19:11:22 +0200

> package assertions in the XML, but you could if you wanted gargantuan

Sure. But without some kind of controlled extensions, in a scenario
like e.g. weather forecasts you'd end up having to send the
human-readable data in an Atom feed and the machine-readable in
external documents (a parallel RSS 1.0 feed?). That is of course
assuming Atom had a mechanism for pointing to the external
documents...

Bottom line is there's no need to include assertions like the date or
material such as content in a feed either. But it all helps make
useful and interesting applications easier.

Cheers,
Danny.

-- 

http://dannyayers.com

---

From: Robert Sayre <[email-masked]>
Date: Sat, 09 Oct 2004 13:20:38 -0400

Danny Ayers wrote:
> external documents (a parallel RSS 1.0 feed?). 
>

Is there a problem with using rdf/xml in extensions? Wouldn't want to 
reinvent RDF.

Robert Sayre

---

From: Tim Bray <[email-masked]>
Date: Sat, 09 Oct 2004 10:21:14 -0700

On Oct 9, 2004, at 9:30 AM, Danny Ayers wrote:

> as long as there is still a uniform means of defining

Is this a requirement for Atom?  I suggest that it's not.  I'd be 
interested in hearing arguments from prior syndication art or from our 
charter. -Tim

---

From: Antone Roundy <[email-masked]>
Date: Sat, 9 Oct 2004 11:22:50 -0600

On Saturday, October 9, 2004, at 11:06  AM, Robert Sayre wrote:
>> used to retrieve a primary resource.  By "primary resource" I mean 
>> for example, an HTML page.  The HTML page itself may contain pointers 
>> to stylesheets, images, etc., which will also be retrieved, but 
>> which, in that context, are not the primary resources.  That's not to 
>> say that those other resources couldn't, in some other context, be 
>> primary resources.  In such a context, it would be appropriate for 
>> <link> to point to them.
>
> Hmmm. I don't think I understand the distinction you are trying to 
> make. Perhaps you mean resources that would be the focus of a primary 
> viewing window? I don't think requirements on UA behavior are 
> in-bounds here.[0]

Let me give another example. In an HTML page, <a href="..."> points to 
something the publisher intends to have traversed in response to 
explicit user interaction, ie clicking.  <img src="..."> points to a 
resource that the publisher intends to have loaded automatically and 
embedded into the presentation of the HTML that contains it.  <link 
rel="stylesheet" href="..."> points to a resource that the publisher 
intends to have loaded automatically and used to guide the presentation 
of the HTML that contains it.  html:a -> atom:link.  html:img -> 
something else.  html:link[@rel="stylesheet"] -> something else.

> UAs can make that decision based on type attributes, HEAD requests, 

Not by my thinking.  Note the distinction between the following:

<a href="puppies.jpeg">Photo of Puppies</a>
<img src="puppies.jpeg" alt="Photo of Puppies">

---

From: Robert Sayre <[email-masked]>
Date: Sat, 09 Oct 2004 13:36:45 -0400

Antone Roundy wrote:

> 
> html:a -> atom:link.  html:img -> 

html:img --> this is more generally called "inclusion". We let you do 
it. Once, maybe. Content@src.

html:link[@rel="stylesheet"] --> 1.) broken, 2.) we don't have it

> <img src="puppies.jpeg" alt="Photo of Puppies">

atom:link is analogous to the anchor, but it has no presentation context.

Robert Sayre

---

From: Danny Ayers <[email-masked]>
Date: Sat, 9 Oct 2004 20:19:08 +0200

On Sat, 09 Oct 2004 10:21:14 -0700, Tim Bray <[email-masked]> wrote:
> Is this a requirement for Atom?

Yes, I believe it is, and most definitely should be.

  I suggest that it's not.  I'd be
> interested in hearing arguments from prior syndication art or from our
 
The charter says:
[[
The format must be able to represent additional information in an
user-extensible manner.
...
The Working Group will also take steps to ensure interoperability, by.
..describing how one migrates from the various RSS versions to the
Atom syndication feed format.
]]

The latter aspect is probably most significant in this discussion. You
can add information to an RSS 1.0 feed featuring arbitrary
relationships (properties). Producers and consumers that support RSS
1.0's model can uniformly interpret that information. A system
migrated to Atom without support of this kind would lose a significant
facility.

Prior syndication art - RSS 1.0 fully supports it, e.g. there's a
WordPress plugin to add terms from FOAF to give more info re. topics,
authors etc:

http://www.wasab.dk/morten/blog/feed/rdf

Nature makes extensive use of the PRISM vocabularies:

http://npg.nature.com/npg/servlet/Content?data=xml/02_newsfeed.xml&style=xml/02_newsfeed.xsl

It's true that most RSS 1.0 producers and consumers only support
enough of RDF to be able to get the data into their application model
(or simply display it). But one thing this shows is that total
commitment to a model isn't needed - really simple tools can still
produce and consume RSS 1.0, despite it being declared to be a
difficult syntax by a lot of people. There are sophisticated RDF tools
around, and their number is growing - all of them support RSS 1.0 out
of the box.

Atom will (hopefully) have a syntax that will be considered simple.
There is no suggestion here that it should support a model like RDF,
just some form of mechanism or convention that will allow it to do a
reasonable proportion of what RSS 1.0 can do.

Cheers,
Danny.

-- 

http://dannyayers.com

---

From: Robert Sayre <[email-masked]>
Date: Sat, 09 Oct 2004 15:10:37 -0400

Danny Ayers wrote:

> Producers and consumers that support RSS

The kicker here is that consumers don't support RSS1.0's model because 
it isn't helpful. The tricky part of supporting an extension is writing 
the handler.

> reasonable proportion of what RSS 1.0 can do.

Show me an example of a client doing something useful with the 
extensions in those two feeds. Then, tell me why it would be impossible 
or harder in Atom.

Robert Sayre

---

From: Danny Ayers <[email-masked]>
Date: Sun, 10 Oct 2004 00:02:39 +0200

Sorry, forgot the links:

BrownSauce:
http://jena.hpl.hp.com:3030/brownsauce/index.html

Source:
http://www.nature.com/nature/journal/v431/n7009/rss.rdf
Resource:
http://dx.doi.org/10.1038/431613a

Source:
http://www.wasab.dk/morten/blog/feed/rdf
Resource:
http://www.wasab.dk/morten/blog/archives/2004/09/30/aggregating-and-archiving-rss-items

On Sun, 10 Oct 2004 00:00:50 +0200, Danny Ayers <[email-masked]> wrote:
> On Sat, 09 Oct 2004 15:10:37 -0400, Robert Sayre <[email-masked]> wrote:
> > Danny Ayers wrote:
> >
> Several syndication-oriented consumers do support RSS 1.0's model, and
> all RDF tools (that support the standard interchange format) support
> RSS 1.0. There are lots of them (see
> http://www.ilrt.bris.ac.uk/discovery/rdf/resources/#sec-tools).
> 
> The model can be extremely useful, especially when you want to mix
> data from different domains. Urchin is a pretty good example:
> http://urchin.sourceforge.net/docs/Design.html
> 
> Matt Biddulph has some good RSS+FOAF material:
> http://www.hackdiary.com/archives/000020.html
> http://www.hackdiary.com/projects/chumpologica/
> 
> > extensions in those two feeds.
> 
> Ok, try BrownSauce - it's not exactly a wonderful visualization (it's
> designed for displaying completely arbitrary data), but it'll do for
> demonstration purpose. Links below.
> 
> One of the displayed lines from the rss:item in the Nature feed is:
> Source: Nature 431, 613 (2004)
> 
> Part of the display of the rss:item from Morten's feed is:
> # topic:
>     * RSS
>     * Title: RSS
>     * page: RSS
> 
> Then, tell me why it would be impossible
> > or harder in Atom.
> 
> The displays are based on a interpretation of the data based on the
> semantics encoded in RDF/XML, specifically how a relationship defined
> in an external namespace is associated between a resource in the RSS
> feed and other data/resources. Atom has no such mechanism. The tool is
> rendering the data consistently across all (unknown) relationships,
> potentially expressed in different syntax styles, but following the
> rules of RSS 1.0. Can't be done in Atom.
> 
> I know it's not exactly a mindblowing display, I'll see what I can
> find with a bit more glitz. (Using the chumpalogica to aggregate from
> the feeds and then doing a FOAF-based query on the data in Redland
> might be nice...) But it does what you asked.
> 
> <rambling-opinion>
> There seems to be a tendency around these parts to take a very narrow
> view of what a tool that uses syndication formats should be like. This
> being based on the implementations that have appeared in the last year
> or so - ok, not too surprising considering desktop aggregators have
> only been around for maybe 3 years.  But all due respect to their
> developers, but the current versions of BlogLines and RssBandit might
> be very useful but they aren't the end of the story, they're the
> beginning.
> 
> Kind of reminds me of when, years back, my mother got herself an
> Amstrad Word Processor. Took me ages to convince her it was a
> computer.
> </rambling-opinion>
> 
> 
> 
> Cheers,
> Danny.
> 
> --
> 
> http://dannyayers.com
> 

-- 

http://dannyayers.com

---

From: Danny Ayers <[email-masked]>
Date: Sun, 10 Oct 2004 00:00:50 +0200

<rambling-opinion>

Cheers,
Danny.

-- 

http://dannyayers.com

---

From: Robert Sayre <[email-masked]>
Date: Sat, 09 Oct 2004 18:42:08 -0400

Danny Ayers wrote:

> feed and other data/resources. Atom has no such mechanism. 

Oh, ok. You want a place to put properties. That makes sense. Here is my 
proposal:

1.) Properties of atom:entry are child elements of atom:entry
2.) Properties of atom:feed go in atom:head
3.) There is no other place to put extension elements in Atom 1.0

Note that these extensions can be arbitrarily complex (you can even use 
RDF :).

Basically, this means none of the Atom-defined "Common Atom Constructs" 
are extensible, although atom:content has a "blob" property.

Off-the-top-of-my-head methods for dealing with existing "Common Atom 
Constructs":

1.) Content Construct
     You have a "blob". Use it if you have "special" content. A prop
     on atom:entry would probably do otherwise.

2.) Person Construct
     "But I want to put FOAF in!" No, you want to relate FOAF
     information to this entry AND a person. If you have general
     person information, it would be bad to boxcar lots of personal info
     in an entry. If it relates to the entry, it can be a prop of entry.
     If you need to relate extension data to the Person Construct, that
     construct provides a handy URI. Refer to it.

3.) Date Construct
     Don't extend this. Add a new kind of date.

4.) Identity Constructs
     Don't extend this.

5.) Text Constructs (coming soon to a spec near you!)
     Don't extend this.

6.) Link Constructs
     "But I want an extra attribute!" No, you want to enclose the Link
     Construct in an extension element.

> view of what a tool that uses syndication formats should be like...

No, there is a very narrow view of the type of information that is 
useful in this format, especially in core. General-purpose assertions 
are not demonstrably useful in this space, but taking steps to make sure 
they work seems reasonable.

Robert Sayre

---

From: Dare Obasanjo <[email-masked]>
Date: Sat, 9 Oct 2004 17:16:46 -0700 (PDT)

> are extensible, although atom:content has a "blob"

<me-too>I almost agree with this entire email
100%</me-too> 

I'm partial to allowing some form of extensibility in
link constructs IFF a clear and concise definition of
what it means to be 'link' makes it into the spec. 

=====

---

From: Danny Ayers <[email-masked]>
Date: Sun, 10 Oct 2004 12:39:29 +0200

> > complex (you can even use

Broad strokes, but I think the kind of extension constraints I believe
Atom needs could be provided this way.

Some details probably need to be taken into account, things like the
conceptual role of attributes, so  core syntax can be seen to be
consistent with core+extensions. But yeah, I reckon this is defintiely
in the right direction.

I'm not sure either way, but this part seems a bit
quirky/capricious/irrational/inexplicable (the thesaurus couldn't give
me the exact word I was after) :

> > are extensible, 

Why shouldn't they be? If for example the information relates to the
date of an entry (e.g. the value in the Indian Calendar), wouldn't it
make sense to associate this with the Date Construct, and include it
inside/alongside?

Referring back to the use of FOAF in RSS 1.0, one option is in the
rss:item (corresponding to the atom:entry, which kind-of follows the
approach you describe - example here:

http://feeds.feedburner.com/BenHammersleysDangerousPrecedent

Contributors are placed inside the entry, but additional data about
the person is placed  *inside* that. It works, but I'm not convinced
this is near the ideal. If there's already a clearly demarcated place
in the format for person-related details (i.e. the Person Construct),
should n't person-related extension stuff go in there?

Ok, if all the subjects of "Common Atom Constructs" have URIs, then as
you say the additional info can be asserted elsewhere. But where?
Placing it in a content blob seems highly inappropriate. Could/should
we e.g. put details of the contributors (expressed in non-Atom
language) in the head?

This could probably do with passing onto danbri and the FOAFnauts for
comment, if your suggestion is adequate for FOAF then it'll probably
cover anything anyone cares to throw at it.

> <me-too>I almost agree with this entire email

<me-too/>

Which is an unusual and promising sign ;-)

> what it means to be 'link' makes it into the spec.

Ditto, ditto. I think the sense of 'link' intended in most of the
discussions so far can be seen as a special case of the more general
properties Robert has laid out.

Cheers,
Danny.

---

From: Graham <[email-masked]>
Date: Sun, 10 Oct 2004 14:18:39 +0100

> Why aren't URIs practicable?

I didn't say they weren't. If you think they are, argue against the 
motion using them as an example.

(btw Is there a Pace for them?)

Graham

---

From: Danny Ayers <[email-masked]>
Date: Sun, 10 Oct 2004 17:29:02 +0200

> motion using them as an example.

Hmm, strange process thing, but a motion is usually a proposal put to
the vote. The above appears to be an (unsubstantiated, controversial)
statement.

> (btw Is there a Pace for them?)

There is now:

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

But it might not be needed if the current link/relationship branches
prove fruitful.

Cheers,
Danny.

-- 

http://dannyayers.com

---

From: Robert Sayre <[email-masked]>
Date: Sun, 10 Oct 2004 11:33:02 -0400

[more assertions]

> me the exact word I was after) :

E, all of the above. But, I still think it's the right thing to do.

> make sense to associate this with the Date Construct, and include it

I doubt you need to extend the Date Construct to do this. Show us an 
example.

> should n't person-related extension stuff go in there?

Atom extensibility is geared towards entries. Everything else should be 
crushingly simple and not extensible.

FOAF data is not the same thing as atom:person. They are two 
vocabularies with similar goals, but they are not composable. If the 
FOAF standard was somewhere an IETF standard could cite it, it might be 
a good fit for Atom, but Atom doesn't need to provide general purpose 
person information. Worst case, everyone starts using FOAF and they have 
to duplicate a couple things. FOAF advocates don't appear to be 
bandwidth conservationists.

> Ok, if all the subjects of "Common Atom Constructs" have URIs, 

They don't have URIs in the sense you're thinking of. The atom:entry is 
the end of the line. Things with URIs are located physically outside of 
the entry.

> then as

Robert Sayre