Subject: AtomAsRDF

From: Tim Bray <[email-masked]>
Date: Fri, 21 Jan 2005 18:57:05 -0800

I just read this, and it's moving toward being a usable Pace, but it 
isn't one yet.  Could Henry or someone please update it so it has 
*specific* suggestions for language changes to the draft, then we can 
see if it gets consensus support.  -Tim

---

From: Robert Sayre <[email-masked]>
Date: Fri, 21 Jan 2005 22:31:53 -0500

Tim Bray wrote:
> see if it gets consensus support. 
> 

I agree, but one point mentioned there is bothering me.

"Atom attributes are not in the atom namespace. It is deprecated in rdf 
for this to be the case.  (so I suppose this means it is still possible)."

What course of action can we take with that?

Robert Sayre

---

From: Danny Ayers <[email-masked]>
Date: Sat, 22 Jan 2005 13:31:20 +0100

> > see if it gets consensus support.

Yep, maybe even put Pace in the title just for convention's sake.

> What course of action can we take with that?

My guess is there's no will to namespace-qualify all the core
attributes. So I reckon the easiest course would be say that each of
the attributes has a namespace-qualified shadow with the same meaning.
When expressed as an RDF vocabulary, Atom will use these attributes.
Whether or not general Atom users should have the option to use these
is another question (probably best avoided in this context).

Cheers,
Danny.

-- 

http://dannyayers.com

---

From: Bill de hÓra <[email-masked]>
Date: Sat, 22 Jan 2005 14:24:56 +0000

> What course of action can we take with that?

1. specify that processors should interpret unprefixed attributes in 
atom namespaced elements to be in the atom namespace. This is idiom as 
specification.

2. specify that all our attributes are to be prefixed. This is 
specification as overkill.

3. mutter darkly about that damnable namespaces spec, and do nothing :)

I've seen heated arguments over 1 and 2. The argument for 1 is that you 
only need prefixes for cases where you're dropping attributes into other 
people's elements, for your own elements prefixes are effectively 
redundant. The argument for 2 is based on the fact that there's a hole 
in the ns spec, screw idiom or effective redundancy.

RDF requires XML artefacts are mapped onto URIs; it's much easier to do 
that if you know what the full QNames are to begin with.

My preference is for 2.

cheers
Bill

---

From: Tim Bray <[email-masked]>
Date: Sat, 22 Jan 2005 10:07:36 -0800

> My preference is for 2.

Blecch.  As in, ugly and wasteful. -Tim

---

From: Danny Ayers <[email-masked]>
Date: Sat, 22 Jan 2005 19:05:39 +0100

> My preference is for 2.

Ah, perhaps I was second-guessing about that being unlikely to get
support. Personally I'd prefer 2 as well, after having recently
experienced confusion over no-namespace attributes (after having
worked with XML plenty long enough that I should have known better
;-).

Cheers,
Danny.
-- 

http://dannyayers.com

---

From: Henry Story <[email-masked]>
Date: Sat, 22 Jan 2005 19:31:12 +0100

I'll put all solutions up on the Pace when I get time.

I think 1. is good enough myself. I imagine that perhaps a future 
version of XML will by default put non namespaced attributes in the 
default namespace, no? In which case things will work out ok in the 
long term.

If there are any other solutions, we should add them to the list.

Henry

On 22 Jan 2005, at 19:07, Tim Bray wrote:

>> atom namespaced elements to be in the atom namespace. This is idiom 
>> as specification.
>>

---

From: Graham <[email-masked]>
Date: Sat, 22 Jan 2005 18:38:55 +0000

> atom namespaced elements to be in the atom namespace. This is idiom as 

This would only be required for mapping to RDF? It wouldn't effect 
other processors?

> specification as overkill.

Nyet.

> 3. mutter darkly about that damnable namespaces spec, and do nothing :)

OK.

Graham

---

From: Tim Bray <[email-masked]>
Date: Sat, 22 Jan 2005 10:50:13 -0800

> I'll put all solutions up on the Pace when I get time.

Then you need multiple different Paces.  A Pace isn't real unless it 
makes a specific suggestion along the lines of "add/replace this 
language".

> default namespace, no? In which case things will work out ok in the 

There is zero chance of that happening.  Whether or not you like the 
current behavior (a majority, but not everybody, dislikes it), we're 
stuck with it. -Tim

---

From: Bill de hÓra <[email-masked]>
Date: Sun, 23 Jan 2005 00:06:57 +0000

> Blecch.  As in, ugly and wasteful. -Tim

I feel the same way. Did you have a robust suggestion?

cheers
Bill

---

From: Martin Duerst <[email-masked]>
Date: Mon, 24 Jan 2005 12:12:50 +0900

At 03:07 05/01/23, Tim Bray wrote:
 >
 >On Jan 22, 2005, at 6:24 AM, Bill de hモra wrote:
 >
 >Blecch.  As in, ugly and wasteful. -Tim

My preference is for 1, too. After all, we are doing "Atom as RDF",
not "Atom is RDF", here, in which case 1 is all we need, and it's
definitely easier for people not involved in RDF.

Regards,    Martin.

---

From: Henry Story <[email-masked]>
Date: Mon, 24 Jan 2005 10:02:49 +0100

I agree with Martin Dürst's analysis.

I have added the following to the AtomAsRDF [1] proposal.

  Text close to the following should appear in the spec (please make 
more precise)
  "Processors should interpret unprefixed attributes in atom namespaced 
elements to be in the atom namespace"

This seems good enough for what we need, and should cause absolutely no 
difficulty
for non-rdf aware parsers.

There is a section "Rejected Solutions" which mentions solution 2. This 
is to help people coming to the discussion get an overview of how we 
came to our decision, and
perhaps notice an oversight.

Henry Story
http://bblfish.net/blog/

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

On 24 Jan 2005, at 04:12, Martin Duerst wrote:

> >> 1. specify that processors should interpret unprefixed attributes 
> in atom namespaced elements to be in the atom namespace. This is idiom 
> as specification.
> >>

---

From: Tim Bray <[email-masked]>
Date: Mon, 24 Jan 2005 08:35:37 -0800

> elements to be in the atom namespace"

Who are you asking to make it more precise? -Tim

---

From: Henry Story <[email-masked]>
Date: Mon, 24 Jan 2005 18:01:58 +0100

On 24 Jan 2005, at 17:35, Tim Bray wrote:

>>  "Processors should interpret unprefixed attributes in atom 
>> namespaced elements to be in the atom namespace"
>

whoever knows for example where it would be best placed in the spec, if 
it should replace some other sentence, if SHOULD should be capitalized, 
...

These are the kind of problems I think we are left with now on this 
issue.

Perhaps they can be left until later whilst we deal with other similar 
sized problems. I believe one should leave the end game moves to the 
endgame and not try to work out details before the time is ready for 
them. Anyway that is what I learnt playing Go [1], and it seems to 
apply to all kinds of areas.

Henry

[1] http://en.wikipedia.org/wiki/Go_%28board_game%29

---

From: Tim Bray <[email-masked]>
Date: Mon, 24 Jan 2005 09:20:40 -0800

On Jan 24, 2005, at 9:01 AM, Henry Story wrote:

> whoever knows for example where it would be best placed in the spec, 
> if it should replace some other sentence, if SHOULD should be 
> capitalized, ...

You don't understand.  The only reality is the actual text in the spec. 
  Nothing else exists.  Until there is an actual proposal for THE ACTUAL 
WORDS that are going into the spec, there is nothing.  The reason is 
that after this WG goes away (which it will), the only communication 
between us and the future is the content of the specification.  It is 
the only subject on which we can have a meaningful debate.

Serious discussion of this subject will not start until there is an 
actual proposal placed before the WG. --Tim

---

From: Henry Story <[email-masked]>
Date: Mon, 24 Jan 2005 20:45:31 +0100

We are all working together on the proposal, in an iterative fashion.
This is very similar to the way one develops  software projects in Agile
or Extreme programming methodology.  First one starts with a prototype.
One gets the major pieces in place, and gets general feedback from the 
clients.
One checks that it works. Then one iteratively works towards a goal of 
getting
something that satisfies the clients needs and budget.

But you are correct to demand some real code. I have branched off the 
particular
topic in AtomAsRDF_PaceAttributesNS [1], so that those that only want 
to work on
detailed text, can get going debating and refining that.

I would be very thankful if someone with more specification experience 
could get
it into the correct final format.

Yours sincerely,

	Henry Story

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

On 24 Jan 2005, at 18:20, Tim Bray wrote:
> You don't understand.  The only reality is the actual text in the 
> spec.  Nothing else exists.  Until there is an actual proposal for THE 
> ACTUAL WORDS that are going into the spec, there is nothing.  The 
> reason is that after this WG goes away (which it will), the only 
> communication between us and the future is the content of the 
> specification.  It is the only subject on which we can have a 
> meaningful debate.
>

---

From: Danny Ayers <[email-masked]>
Date: Mon, 24 Jan 2005 22:03:22 +0100

"running code" ;-)

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

== Abstract ==

Allow processors to interpret Atom attributes as being within the Atom
namespace.

== Status ==

Open

== Rationale ==

Atom attributes are not in a namespace, which is likely to cause
problems with interpretation of Atom documents by systems (such as
RDF) which require absolutely qualified terms.

== Proposal ==

To be inserted: 
{{{
Section 2.  Atom Documents

Atom processors MAY interpret unprefixed attribute names as their
namespace-qualified equivalents.
If they do, then all Atom attribute names MUST appear in the Atom namespace.

}}}

== Impacts ==

None

== Notes ==

----

CategoryProposals

-- 

http://dannyayers.com

---

From: Sam Ruby <[email-masked]>
Date: Mon, 24 Jan 2005 16:38:52 -0500

Henry Story wrote:
> topic in AtomAsRDF_PaceAttributesNS [1], so that those that only want to 
> work on

It is not "code" that Tim is asking for, but merely words.  The 
specification is but a set of paragraphs, and somebody needs to say 
"insert <these> words <there>".

As to the words that you have proposed, I have a technical question: if 
you are equating unnamed attributes with attributes in the atom 
namespace, then everybody who looks today for an href attribute would 
*also* have to look for an atom:href attribute.  Multiply this by all of 
the attributes defined in the specification, and IMHO, you have a 
solution that is *worse* than requiring the atom namespace in the first 
place.  So,

   -1

 From my perspective, Atom can be one XSLT translation away from 
RDF/XML, and will likely remain such.  We can capture that translation 
as a non-normative appendix to the spec.  We can also look at GRDDL or 
other techniques for making this explicit in the documents.  But what I 
don't want is to make the syntax dramatially worse for people who want 
to use simple XML processing tools.

- Sam Ruby

---

From: Antone Roundy <[email-masked]>
Date: Mon, 24 Jan 2005 14:52:52 -0700

> If they do, then all Atom attribute names MUST appear in the Atom 
I'd suggest slightly different language, such as:

"Atom processors MAY interpret unprefixed attribute names in elements 
from the Atom namespace as if they were in the Atom namespace."

Why I prefer the above:

1) It explicitly applies this rule only to Atom core elements--not 
extensions.
2) "their namespace-qualified equivalents": Unless the spec defines 
namespace-qualified attributes for Atom, which it doesn't, 
namespace-qualified equivalents don't actually exist, right?
3) It combines the two sentences, which I think is more clear.

---

From: Danny Ayers <[email-masked]>
Date: Tue, 25 Jan 2005 00:42:57 +0100

> 3) It combines the two sentences, which I think is more clear.

Yep, I reckon that's an improvement.

One thing I'm not sure about - where it currently says "Atom
processors", perhaps that would be better as merely "Atom consumers".
For the reasons Sam gave, we don't really want extra variability in
what's being produced, but this still would still allow RDF-like
consumers to interpret the feed as an RDF-like language.
Does that make sense, or is there a case I'm missing here?

Cheers,
Danny.

-- 

http://dannyayers.com

---

From: Henry Story <[email-masked]>
Date: Tue, 25 Jan 2005 02:53:54 +0100

On 24 Jan 2005, at 22:38, Sam Ruby wrote:
>> One gets the major pieces in place, and gets general feedback from 
>> the clients.
>> One checks that it works. Then one iteratively works towards a goal 
>> of getting
>> I would be very thankful if someone with more specification 
>> experience could get

I was using metaphorical language above, comparing methods taken from 
software engineering to the work of developing a spec. To be more 
precise spec writing was the
tenor of the metaphor and software engineering the vehicle [1], and 
code perhaps the ground. I was taking properties from the software 
engineering vocabulary and applying them metaphorically to spec 
development.

> As to the words that you have proposed, I have a technical question: 
> if you are equating unnamed attributes with attributes in the atom 
> *also* have to look for an atom:href attribute.  Multiply this by all 
> of the attributes defined in the specification, and IMHO, you have a 
> solution that is *worse* than requiring the atom namespace in the 
> first place.  So,

I think Danny Ayers had a more complete proposal: 
PaceAttributesNamespace.

> RDF/XML, and will likely remain such.

The point of the trying to get the two closer together is that it makes 
it easier to
explain very clearly structured extensibility.

>  We can capture that translation as a non-normative appendix to the 
> spec.  We can also look at GRDDL or other techniques for making this 
> explicit in the documents.  But what I don't want is to make the 
> syntax dramatially worse for people who want to use simple XML 
> processing tools.

There is absolutely no impact on syntax. I think Danny's pace makes 
that clear.

> - Sam Ruby

[1] http://en.wikipedia.org/wiki/Metaphor

---

From: Antone Roundy <[email-masked]>
Date: Mon, 24 Jan 2005 19:24:42 -0700

> Does that make sense, or is there a case I'm missing here?
Agreed--"consumers" is better. Perhaps language should also be added to 
ensure that people know that they're not supposed to actually add a 
namespace prefix to the attributes. For example:

"Atom consumers MAY interpret unprefixed attribute names in elements 
from the Atom namespace as if they were in the Atom namespace. However, 
Atom producers MUST NOT add a namespace prefix to attributes defined by 
the Atom format specification."

BTW, am I remembering correctly that "xml:" in "xml:lang" and 
"xml:base" isn't a namespace prefix? You don't see xmlns:xml="..."--so 
is "xml:" not a namespace prefix, or does it just not have to be 
declared?  If it IS a namespace prefix, then the above language works 
only if you don't consider publishing "xml:base" and "xml:lang" to be 
ADDING the prefix, since it was already there in the spec, but it may 
be possible to word it better.

---

From: Sam Ruby <[email-masked]>
Date: Mon, 24 Jan 2005 21:35:37 -0500

> Does that make sense, or is there a case I'm missing here?

I'm still struggling to understand what this is for.  So, let me ramble 
for a few minutes...

Assuming that there will be an XSLT which maps Atom to RDF, such an XSLT 
will have to map all unnamespaced attributes into something with a 
namespace.  The namespace of the element is a reasonable choice.

I'm a bit concerned about precedence rules (what happens if there is an 
href attribute *AND* an atom:href attribute?).  What makes most sense 
here is for a prohibition disallowing such in any exension.  I would 
support such a rule.

Finally, I'm a bit concerned about round tripping - i.e., producing 
valid feeds from an RDF triple store.  Given that an unnamespaced 
attribute and a namespaced attribute are two different things - how can 
a valid feed be produced?

- Sam Ruby

---

From: Martin Duerst <[email-masked]>
Date: Tue, 25 Jan 2005 11:42:14 +0900

clients.
 >> One checks that it works. Then one iteratively works towards a goal of getting
particular
to work on
could get
 >It is not "code" that Tim is asking for, but merely words.  The 
specification is but a set of paragraphs, and somebody needs to say "insert 
<these> words <there>".
 >As to the words that you have proposed, I have a technical question: if 
you are equating unnamed attributes with attributes in the atom namespace, 
then everybody who looks today for an href attribute would *also* have to 
look for an atom:href attribute.  Multiply this by all of the attributes 
defined in the specification, and IMHO, you have a solution that is *worse* 
than requiring the atom namespace in the first place.  So,

That's not the way I have understood this. What I thought this to
be is: In Atom, these attributes always are unprefixed. They are
in the Atom namespace just for the purposes of RDF.

 > From my perspective, Atom can be one XSLT translation away from RDF/XML, 
and will likely remain such.  We can capture that translation as a 
non-normative appendix to the spec.  We can also look at GRDDL or other 
techniques for making this explicit in the documents.  But what I don't 
want is to make the syntax dramatially worse for people who want to use 
simple XML processing tools.

Agreed. I just saw the text that we would insert into the spec as
a verbal description of one aspect (adding an Atom-namespace prefix)
of that transformation. But I can see that the current text,
"Processors should interpret unprefixed attributes in atom namespaced
elements to be in the atom namespace", can easily be interpreted
the way you have done it. I think this can be fixed by changing it
to something like
"For the purpose of transformation to or interpretation as RDF,
unprefixed attributes in atom namespaced elements to be interpreted
as being in the atom namespace."

I guess that Henry didn't add the clarification because he saw
the text in the context of an overall AtomAsRDF section, which
would make the context clear enough.

Regards,    Martin.

---

From: Sam Ruby <[email-masked]>
Date: Mon, 24 Jan 2005 22:06:01 -0500

Antone Roundy wrote:
> 
> BTW, am I remembering correctly that "xml:" in "xml:lang" and "xml:base" 
> isn't a namespace prefix? You don't see xmlns:xml="..."--so is "xml:" 
> not a namespace prefix, or does it just not have to be declared?  If it 
> IS a namespace prefix, then the above language works only if you don't 
> consider publishing "xml:base" and "xml:lang" to be ADDING the prefix, 
> since it was already there in the spec, but it may be possible to word 
> it better.

Essentially, xml: is predeclared for you.  See:

http://www.w3.org/TR/1999/REC-xml-names-19990114/#nsc-NSDeclared

- Sam Ruby

---

From: Bjoern Hoehrmann <[email-masked]>
Date: Tue, 25 Jan 2005 04:34:44 +0100

>be possible to word it better.

<http://www.w3.org/XML/xml-names-19990114-errata>:

[...]
  The prefix xml is by definition bound to the namespace name
  http://www.w3.org/XML/1998/namespace. It may, but need not,
  be declared, and must not be bound to any other namespace
  name. No other prefix may be bound to this namespace name. 
[...]
-- 
Björn Höhrmann · mailto:[email-masked] · http://bjoern.hoehrmann.de
Weinh. Str. 22 · Telefon: +49(0)621/4309674 · http://www.bjoernsworld.de
68309 Mannheim · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/

---

From: Bjoern Hoehrmann <[email-masked]>
Date: Tue, 25 Jan 2005 04:33:35 +0100

>If they do, then all Atom attribute names MUST appear in the Atom namespace.

This does not make much sense to me, it is either not possible to write
a test case for the first requirement in which case this would be an im-
plementation detail which is out of scope of the specification, or it is
possible to write such a test case in which case this would render Atom
inconsistent with a broad range of XML technologies, e.g., for

  <atom:foo bar="baz" />

an XPath expression

  *[namespace-uri() = $x)]/@*[namespace-uri() = $x]

where $x is the Atom namespace URI would be allowed to match. I am -1 on
any proposal that allows or requires to put Atom-defined attributes on
Atom elements in any namespace or process Atom documents as if they were
constructed like that if you can tell the difference.
-- 
Björn Höhrmann · mailto:[email-masked] · http://bjoern.hoehrmann.de
Weinh. Str. 22 · Telefon: +49(0)621/4309674 · http://www.bjoernsworld.de
68309 Mannheim · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/

---

From: Bjoern Hoehrmann <[email-masked]>
Date: Tue, 25 Jan 2005 04:47:49 +0100

>here is for a prohibition disallowing such in any exension.  I would 

Allowing either atom:href or href is not a good idea either, you have to
check for both attributes each time you access it and if having both at
the same time is not allowed or causes undefined behavior, you need to
avoid that, turning

  x.setAttributeNS(null, 'foo', 'bar');

into

   if (x.hasAttributeNS(null, 'foo') &&
       x.hasAttributeNS(atom, 'foo'))
   {
      throw "...";
   }
   else
   {
       x.removeAttributeNS(atom, 'atom');
       x.setAttributeNS(null, 'foo', 'bar');
   }

This might not be too relevant for some Atom implementations, but if you
implement Atom through SVG 1.2 + sXBL + ECMAScript, the result would not
be pretty.
-- 
Björn Höhrmann · mailto:[email-masked] · http://bjoern.hoehrmann.de
Weinh. Str. 22 · Telefon: +49(0)621/4309674 · http://www.bjoernsworld.de
68309 Mannheim · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/

---

From: Danny Ayers <[email-masked]>
Date: Tue, 25 Jan 2005 11:28:08 +0100

> namespace.  The namespace of the element is a reasonable choice.

I'm not sure whether it'll be a good strategy to allow no-namespace
attributes in extensions - extension-creators may want to use terms
from within the Atom namespace in other elements (although I guess
they could use the qualified versions), and
 it also feels like it might complicate handling (if this wasn't
allowed then 'namespace of element' would still be the rule, except
that namespace would always be Atom's).

I realise XSLT/GRDDL is the obvious target for this stuff, but I worry
a little about thinking in terms of a particular processing model. It
would be nice for example if the DTD defaults could be used as a
simple Atom => RDF/XML transformation, although I doubt that's
possible given the namespaced attributes situation (no-namespace
attributes were deprecated in RDF/XML, not sure whether they ever got
banned outright).

> here is for a prohibition disallowing such in any exension.  I would

Yep, that makes sense.

> a valid feed be produced?

Some fairly hardwired coding will be required to constrain the syntax
down to RDF/XML of the right shape anyway, I'm assuming it would only
be a tad more application code to change the attribute namespaces. It
would be a little easier if Atom attributes were always
namespace-qualifie (it would be a lot simpler if Atom were
RDF/XML...).

Cheers,
Danny.

-- 

http://dannyayers.com

---

From: Danny Ayers <[email-masked]>
Date: Tue, 25 Jan 2005 11:45:15 +0100

> inconsistent with a broad range of XML technologies, e.g., for

Sorry, swap in the word 'consumer'. Straight XML applications will see
that exactly as written, languages that require disambiguation of 
'bar' will read it as 'atom:bar'

A test case would be an RDF processor seeing the triples:

_:fooinstance rdf:type atom:foo .
_:fooinstance atom:bar "baz" .

(assuming atom:foo was a class)

Cheers,
Danny.

-- 

http://dannyayers.com

---

From: Danny Ayers <[email-masked]>
Date: Tue, 25 Jan 2005 11:48:47 +0100

> implement Atom through SVG 1.2 + sXBL + ECMAScript, the result would not

Again, I don't think this a problem when the
no-namespace/atom-namespace mapping is only an option for consumers -
unless I'm missing something?

Cheers,
Danny.

-- 

http://dannyayers.com

---

From: Bjoern Hoehrmann <[email-masked]>
Date: Tue, 25 Jan 2005 12:22:24 +0100

>(assuming atom:foo was a class)

If this implementation detail is exposed to the user, it would seem
reasonable to consider such a software a Atom-to-something-else con-
verter; you would thus seem to propose the introduction of conformance
requirements for Atom conversion programs into the specification. No?
-- 
Björn Höhrmann · mailto:[email-masked] · http://bjoern.hoehrmann.de
Weinh. Str. 22 · Telefon: +49(0)621/4309674 · http://www.bjoernsworld.de
68309 Mannheim · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/

---

From: Bjoern Hoehrmann <[email-masked]>
Date: Tue, 25 Jan 2005 12:23:46 +0100

>unless I'm missing something?

I am not sure what you consider a "consumer" in this context, pointer?
-- 
Björn Höhrmann · mailto:[email-masked] · http://bjoern.hoehrmann.de
Weinh. Str. 22 · Telefon: +49(0)621/4309674 · http://www.bjoernsworld.de
68309 Mannheim · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/

---

From: Danny Ayers <[email-masked]>
Date: Tue, 25 Jan 2005 14:19:34 +0100

> requirements for Atom conversion programs into the specification. No?

Not necessarily - although I take your point, it does look very
application oriented and probably impossible to test within the scope
of core Atom. But because it is defining the meaning of terms in the
Atom namespace (atom:type will be equivalent to type) I believe this
information should go in the normative part of the core spec.

Cheers,
Danny.

-- 

http://dannyayers.com