Subject: New AtomPubIssuesList for 2004/10/08

From: Sam Ruby <[email-masked]>
Date: Fri, 08 Oct 2004 13:08:42 -0400

The list this time is rather simple:  the next Date item with the most 
listed supporters, and the biggest outstanding issue with the format.

Given that we have been around these issues before, one thing I would 
like to ask is that people try to avoid making clever, provocative, and 
leading questions, and instead try to provide specific and constructive 
suggestions possible.

So, the issues list at the moment is:

PaceDateOfSubject

PaceLinkAttrDefaults
PaceLinkConstruct
PaceLinkDelicious
PaceLinkParent
PaceLinkPurpose
PaceLinkRelMechanism
PaceLinkTitle
PaceReplaceLinkElement

- Sam Ruby

---

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

> PaceReplaceLinkElement

Given the discussion that's already occurred in the last day, I think 
you need to forget discussing specific proposals and ask some consensus 
finding questions re: the direction in which metadata containing URIs 
can be extended.

Graham

(PS I sent a blank email to Sam while composing this - sorry)

---

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

> finding questions re: the direction in which metadata containing URIs

Yep, though there are kind-of architectural patterns in these Paces,
so I think it may be possible to keep it in the confines of <link> and
break it down a little to get consensus on parts. There are only a few
(in principle, broadly) orthogonal questions, first pass -

* which link rel values should be refactored out into elements in
their own right?

* should [whatever remains of] link have its semantics narrowed? 
(e.g. to "things on which a GET might work", other groupings or totally removed)

* should [whatever remains of] link be used as an extension point?
(later - what relation naming mechanism should be used?) 

Not sure how they can be massaged in with the process though...

Cheers,
Danny.

-- 

http://dannyayers.com

---

From: Sam Ruby <[email-masked]>
Date: Sat, 09 Oct 2004 11:46:42 -0400

> finding questions re: the direction in which metadata containing URIs 

We recently had a round on extensibility.  The mailing list also 
contains a number of people who seem to prefer to traffic in what Dan 
Brickley referred to as a "snipey style of interaction".

I'd like to try to give equal time to the people who can manage to 
express coherent, constructive, and specific suggestions.

- Sam Ruby

---

From: "Clinton Gallagher" <[email-masked]>
Date: Sat, 9 Oct 2004 13:32:54 -0500

I hope this RFI does not get me called any names as they do in the rss-dev
list and due to a simple matter of pressing time conflicts I must admit I
have not studied Atom sufficiently to determine if Atom uses namespaces but
remain compelled regardless to ask for comments regarding the use of
copyright to protect one's use of prefixed namespaces.

If this is not a matter of interest to this list I hope I can encourage
those with well recognized 'names' to be so kind as to refer me to
contemporaneous commentary that speaks to this issue explicitly. I have yet
to be able to find a lawyer with sufficient experience with software
development.

<%= Clinton Gallagher

---

From: Paul Hoffman / IMC <[email-masked]>
Date: Sat, 9 Oct 2004 11:55:55 -0700

>copyright to protect one's use of prefixed namespaces.

No name-calling, but an explicit statement that "this is out of scope 
for the development of Atom". If you want advice about using laws to 
protect something, you really should pay a lawyer.

--Paul Hoffman, Director
--Internet Mail Consortium

---

From: "Clinton Gallagher" <[email-masked]>
Date: Mon, 11 Oct 2004 09:34:44 -0500

Example: 

xmlns:abc="http://smallpotato.com/"
xmlns:abc="http://corporategiant.com/"

Please help me understand how any given derivation of XML such as RSS 1.0,
RSS 2.0, Atom and so on has been created by its authors to avoid ambiguity
and prevent the software process from failing to function when validation is
required when two or more attempts to use the same prefix within a given
document instance occurs?

<%= Clinton Gallagher

---

From: Graham <[email-masked]>
Date: Mon, 11 Oct 2004 16:01:40 +0100

> xmlns:abc="http://corporategiant.com/"

Add some real XML, and the problem becomes solvable. If we declare them 
in the same element:

<element xmlns:abc="http://smallpotato.com/ 
xmlns:abc="http://corporategiant.com/" />

This is invalid XML since attribute names must be unique.

If we declare them in separate elements:

<element xmlns:abc="http://smallpotato.com/ >
   <element xmlns:abc="http://corporategiant.com/">
     <abc:element />
   <element/>
</element>

The innermost one applies. And obviously:

<element xmlns:abc="http://smallpotato.com/" >
   <abc:element />
</element>
<element xmlns:abc="http://corporategiant.com/">
   <abc:element />
<element/>

Applies a different namespace to each one.

Anyway, this isn't what you're asking. The simple answer is: You cannot 
own a namespace prefix. The abc is simply a *temporary* shorthand for 
"http://corporategiant.com/" or "http://smallpotato.com/". It belongs 
(temporarily) to whoever it's been declared to beforehand in the 
document. Anyway, this is wildly offtopic for the Atom list.

Graham

---

From: Sam Ruby <[email-masked]>
Date: Tue, 12 Oct 2004 10:29:23 -0400

> leading questions, and instead try to provide specific and constructive 

I'm pleased to see that some people have taken this suggestion to heart 
and authored the following Paces in this area:

   PaceConstructAttribute
   PaceLinkRelPrefixReg
   PaceLinkRelUri
   PaceRelationshipConstruct

Thanks!

  - - -

It looks to me like PaceLinkRelPrefixReg and PaceRelationshipConstruct 
are taking that atom:link element in two different directions.  I've 
started to pull together a PaceMetaElement in the hopes that these goals 
to be pursued separately and without compromise.

By this point, it is clear that a number of people are concerned about 
the syntax of links, particularly for the common case of alternate 
links.  (Separately, there has been opinion expressed that alternate 
links should not be required, particularly if an atom:content element is 
present, so I've authored PaceContentOrLink to cover that case).

There is a concensus that PaceLinkAttrDefaults goes too far, but very 
little in terms of concrete suggestions as to how far is far enough. 
I'm hopeful that a combination of PaceLinkAttrDefaults and 
PaceLinkRelPrefixReg will address both the syntax concerns and the "far 
enough" concerns.

  - - -

Summary:

   * service in a separate element
   * meta in a separate element
   * link no longer required if content is present
   * default values for link attributes for the common case
   * link rel values subject to IANA registration.

Thoughts?

- Sam Ruby

---

From: "Bill Kearney" <[email-masked]>
Date: Tue, 12 Oct 2004 11:55:13 -0400

> xmlns:abc="http://corporategiant.com/"

It should fail to validate.  One can't use the same prefix for a namespace
within the same document.  Anything attempting to 'blend' or otherwise
combine different XML fragments should take care to avoid this.  It's the
namespace URI that's important, not the prefix.  Likewise, one should
generally avoid trying to use the same namespace URI with more than one
prefix in a single document.

This is also why many XML example documents use things like ns0, ns1, ns2
for the prefixes.

You seem to have some sort of strange ideas about how the prefixes and the
namespaces are supposed to work.  That and your questions/comments about
copyright raise a certain sense of suspicion.  As a result you may find a
general resistance from folks in assisting you.  This may not be your
intention, of course.  If you've got some amazingly clever idea on how to
reap riches based on copyright and/or licensing of prefixes and/or
namespaces you may want to prepare yourself for disappointment.  Interop
does not generally lend itself to such things.

-Bill Kearney
Syndic8.com

---

From: Antone Roundy <[email-masked]>
Date: Tue, 12 Oct 2004 12:44:11 -0600

On Tuesday, October 12, 2004, at 08:29  AM, Sam Ruby wrote:
> are taking that atom:link element in two different directions.

I'm having a difficult time wrapping my brain around 
PaceRelationshipConstruct and figuring out how Atom would benefit from 
it.  Here's what I'm getting:

* if an element has @atom:href
* then
	+ we know that what it points to is somehow related to the parent 
element
* and
	+ if we recognize the element, we also know whatever other things that 
element tells us, which are different on an element-by-element basis
	+ else we don't know anything else about it

Unless there's more to it than that, then I don't see the benefit.  
Basically, we know that atom:href points to something.

The proposed spec text is pretty cryptic to one like I who is not 
versed in the kind of thing (RDF, I assume) that it is based on.  Do we 
need to say "binary"?  What does that mean, exactly, that isn't 
communicated without the word "binary"?  "The nature of the 
relationship is determined by the name of the element...".  Okay, 
that's saying that there's no @rel to define the nature of the 
relationship.  I'm not sure we need that sentence, because I think 
that's what would be expected, absent mention of some other method of 
determining the nature of the relationship.

The next sentence: "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."  That goes without saying, I think.  
Next: "Otherwise the consumer MAY follow whatever definition is 
provided for the the term in the namespace in question."  I don't 
suppose this is intended to imply that consumers are free to 
misinterpret elements from other namespaces.  I don't know that we need 
this sentence.  Next: "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."  It goes without saying that unrecognized elements 
from other namespaces can be ignored (unless we add some sort of 
"mustUnderstand" mechanism).  What manner could possible seem 
appropriate to present an element that you only know one thing about: 
there's something out there that's related to the parent element?

I guess I'm just not catching the vision.  Would it not be more useful 
to be able to tie extension elements to a more tightly defined Atom 
construct, which would give the consumer some basis for applying 
default processing?  Would not unknown extension elements be pretty 
much equally useful without knowing the one piece of information that 
the Relationship Construct gives us?  In other words, how much more can 
an application do with:

<myext:myelem atom:href="...">My data</myext:myelem>

than with:

<myext:myelem myext:href="...">My data</myext:myelem>

> I've started to pull together a PaceMetaElement in the hopes that 
> these goals to be pursued separately and without compromise.

Perhaps once I understand PaceRelationshipConstruct better, I'll 
understand this better too.  A brief example showing the "property" and 
"about" attributes in action would be helpful too (I understand that 
it's a work in progress).  If meta has a @property, does that mean that 
it's talking about its parent element (and that what it's saying is 
determined by the value of @property)?   And if it has an @about, does 
the about point to the things that the element is talking about?  
Finally, am I understanding correctly that as a child of <meta>, <link> 
can have @rel values that are defined in extensions (which must be 
QNames), but as a child of an Atom core element, it is to be limited to 
Atom's list of values?  Or is PaceMetaElement intended to be able to 
coexist with PaceLinkRelPrefixReg or something like it?

---

From: Danny Ayers <[email-masked]>
Date: Sat, 16 Oct 2004 15:50:55 +0200

Sorry Antone, I only just spotted your post.

> Basically, we know that atom:href points to something.

It also points *from* something, and a relationship is defined.

> versed in the kind of thing (RDF, I assume) that it is based on. 

It's based on the URI definition of a resource, XML and XML
namespaces. Sorry if it seems cryptic, my bad, but I was trying to be
formal & unambiguous. (Heh, I used 'relationship' rather than
'relation' to avoid opening another can of worms - looks like I forget
to remove the can opener).

 Do we
> relationship is determined by the name of the element...".  

Yep, "binary" is redundant.

Okay,
> determining the nature of the relationship.

I think it worthwhile making it explicit, as other interpretations may
be possible.

> that term in this specification."  That goes without saying, I think.

Yep, but again it's making it explicit to preempt any confusion.

> misinterpret elements from other namespaces.  

Yes, exactly that, as far as Atom is concerned.

I don't know that we need
> "mustUnderstand" mechanism). 

They could be treated as errors or take some other interpretation
defined elsewhere.

 What manner could possible seem
> there's something out there that's related to the parent element?

At minimum you know three things:

1. the subject of the relation (the resource associated with the parent element)
2. the name of the relation (the namespace-qualified element name)
3. the object of the relation

Through RDF spectacles this is very useful. 

Without those spectacles, how's this scenario: an aggregator stores
the complete feed data it reads. Version 1.0 of the aggregator doesn't
recognise relationX. But version 2.0 does, so after upgrade your tool
can present stored data which includes relationX in an appropriate
fashion.

> default processing?  

Maybe, that's kind-of <link> territory.

Would not unknown extension elements be pretty
> <myext:myelem myext:href="...">My data</myext:myelem>

Nice example. The application can answer the questions: "are there any
other resources related to this (parent element) resource" and "what
are the names of those relationships". What it does with that
information is another question (e.g. it could try and find out what
the relationship means) but the difference is that /something/ rather
than /nothing/ is communicated.

> > these goals to be pursued separately and without compromise.

[snip - I've still not checked this out, the days are definitely
getting shorter...]

Cheers,
Danny.

-- 

http://dannyayers.com

---

From: Robert Sayre <[email-masked]>
Date: Sat, 16 Oct 2004 14:01:51 -0400

>   * service in a separate element

+1. I see this Pace is in the accepted list[0], so it will be in format-03

>   * meta in a separate element

I agree with the goal of PaceMetaElement. It is useful for Atom to 
separate "hypertext linking" from URIs that are "logical information ... 
not intended to be browsed by people as a document." [1]

>   * link rel values subject to IANA registration.

I strongly object to the link @rel syntax, and IANA registration. We 
have a thoroughly tested collision-avoidance mechanism that we use 
everywhere else: XML Namespaces.

I think I understand why some favor the syntax. The draw seems to be its 
approachability. The problem with it is that people think they can use 
it exactly as they do in HTML, which is not what's being proposed. I 
have received off-list email from WG members that make this mistake--not 
a good sign.

It seems worth it to call out hypertext links as special properties of 
an entry. I'd like to see how people respond to this:

<entry>
	<title>...</title>
	<summary>...</summary>
	<id>...</id>
	<links>
		<alternate href="" />
		<my:ext atom:href="">
			[undefined child content]
		</my:ext>
	</links>
	<content>...</content>
</entry>

This would make children of <links> hypertext references, and the Link 
construct would leave child content undefined. Attribute defaults would 
be present. However, Atom core link elements would not allow child 
content. I'll write a Pace if this idea resonates.

Thoughts?

Robert Sayre

[0] http://www.intertwingly.net/wiki/pie/AtomPubIssuesList
[1] http://www.w3.org/DesignIssues/XLink.html
(not saying we should use XLink :) )

---

From: Graham <[email-masked]>
Date: Mon, 18 Oct 2004 16:27:57 +0100

> 			[undefined child content]

+1 to the grouping syntax as a way to appease general purpose linking 
fans. I'm not sure about the child content issue though - I'd think the 
URL or the title should always go in there? Also, the atom:href syntax 
is redundant now - shouldn't it be dropped?

Graham

---

From: Sam Ruby <[email-masked]>
Date: Thu, 28 Oct 2004 13:30:16 -0400

Lets see if we can do some small cleanups:

The next date element with the most sponsors:

   PaceDateModified

Making link not required (in some circumstances):

   PaceContentOrLink
   PaceOptionalAlternateLink

Error reporting:

   PaceErrVerb
   PaceServiceError

Host from mod-wiki:

   PacePersonConstructs

- Sam Ruby

---

From: Danny Ayers <[email-masked]>
Date: Thu, 28 Oct 2004 20:34:30 +0200

PaceDateModified +1

PaceContentOrLink -1 

PaceOptionalAlternateLink +1

PaceErrVerb -1

PaceServiceError +1

PacePersonConstructs +1

Reasons:

PaceDateModified
- atom:updated is very loose, this is tighter 
(the naming is likely to cause confusion, but atom:updated is already
in the bag)

PaceContentOrLink 
- this seems a bit clunky, and already covered by PaceOptionalAlternateLink

PaceOptionalAlternateLink
- all the use cases on the Wiki

PaceErrVerb
- probably has virtue, but pragmatically I think it's out of Atom's scope

PaceServiceError
- worth a try

PacePersonConstructs
- this does seem rather kludgey, but I think the Wiki use case is strong

Cheers,
Danny.

-- 

http://dannyayers.com

---

From: Sam Ruby <[email-masked]>
Date: Thu, 28 Oct 2004 14:50:04 -0400

> - all the use cases on the Wiki

I'm -1 on making AlternateLink completely optional unless the content is 
provided.  The use cases on the wiki seem to all include inline content. 
  Is there a use case for syndication where the content is neither 
included nor referenced?

As I see it PaceContentOrLink coupled with PaceReformedContent3 (already 
approved) provide consumers with a minimum set of guarantees:

   1) All entries will have a displayable text fallback
   2) The content is either inline or can be located

- Sam Ruby

---

From: Danny Ayers <[email-masked]>
Date: Thu, 28 Oct 2004 21:08:28 +0200

>   Is there a use case for syndication where the content is neither

I'm not sure, this is drifting into protocol territory, but might it
not be useful to use a no-content entry to signify removal of an
existing entry?

-- 

http://dannyayers.com

---

From: Tim Bray <[email-masked]>
Date: Thu, 28 Oct 2004 12:07:02 -0700

On Oct 28, 2004, at 11:50 AM, Sam Ruby wrote:

> I'm -1 on making AlternateLink completely optional unless the content 
> is provided.  The use cases on the wiki seem to all include inline 
> content.  Is there a use case for syndication where the content is 
> neither included nor referenced?
>
> As I see it PaceContentOrLink coupled with PaceReformedContent3 
> (already approved) provide consumers with a minimum set of guarantees:

+1. -Tim

---

From: Sam Ruby <[email-masked]>
Date: Thu, 28 Oct 2004 15:23:34 -0400

> not be useful to use a no-content entry to signify removal of an

I believe that's what the DELETE method is used for.

In any case, if content is not provided, then summary is required. 
Having a summary with no way to locate the content seems a bit... strange.

- Sam Ruby

---

From: Danny Ayers <[email-masked]>
Date: Thu, 28 Oct 2004 21:28:39 +0200

> I believe that's what the DELETE method is used for.

Other direction.

> Having a summary with no way to locate the content seems a bit... strange.

True. 

Cheers,
Danny.

-- 

http://dannyayers.com