Subject: PaceAttributesNamespace status

From: Tim Bray <[email-masked]>
Date: Mon, 24 Jan 2005 16:17:53 -0800

Not yet taken up by the WG, depends on the discussion that comes with 
this call. Same rules as all the others: there has to be a positive WG 
consensus that it adds to the base specification.  -Tim

---

From: Joe Gregorio <[email-masked]>
Date: Mon, 24 Jan 2005 20:25:33 -0500

-1 Ick.

The only example given of a case where this may cause others problems
is RDF, and I thought we were going to have a non-normative Atom ->
RDF XSLT? Are there other cases I am unaware of?

    -joe

-- 
Joe Gregorio        http://bitworking.org

---

From: Graham <[email-masked]>
Date: Tue, 25 Jan 2005 01:39:54 +0000

> consensus that it adds to the base specification.  -Tim

-1

Unacceptable. Language is too broad and is meaningless outside the RDF 
context, which is where it should stay.

Graham

---

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

The point is to allow a very clear structure for Atom extensibility to 
be defined, as
specified by the Atom working group charter. See AtomAsRDF and AtomOWL. 
The point
of the exercise is to make this as invisible as possible to anyone 
other than those
who need to write extensions. The intention is for this to have minimal 
impact on the
spec. So if you don't care about writing or parsing atom extension, 
then you need not worry.

Henry Story

---

From: Joe Gregorio <[email-masked]>
Date: Mon, 24 Jan 2005 21:08:45 -0500

> spec. So if you don't care about writing or parsing atom extension,

I was looking for concrete examples beyond RDF, which, as I asserted,
can be covered by an XSLT transformation. Since no others have been
supplied I'll stick to my -1.

    -joe

---

From: Henry Story <[email-masked]>
Date: Tue, 25 Jan 2005 03:23:41 +0100

You can xslt convert anything to anything. That is not very helpful for 
defining
an extensibility framework. Extensibility and  a model are requirements 
for this working group. So these are central concerns.

If you have an xslt based extensibiliy solution then please describe it 
in your own Pace. You will need to define not only how Atom maps to 
your preferred framework, but also how things can be expressed in that 
framework that extend Atom, and then how you
can map the extended framework back into Atom with extensions.

The proposal of which PaceAttributesNamespace is part of, AtomAsRDF, is 
a much simpler
framework. It does not require the double mapping any other solution 
would. With very
slight adjustements - which will be *completely invisible* to the end 
user (no rdf:li,
no rdf:ul, no rdf:anything pretty much) we will be able to specify a 
very precise frameork.

What I don't see is how you can object to a Pace that does not affect 
anything you need on grounds that you object to the aims the Pace is 
trying to fulfill, when those aims are central to the Atom working 
group.

Henry Story

---

From: Bill de hÓra <[email-masked]>
Date: Tue, 25 Jan 2005 14:30:14 +0000

> RDF XSLT? Are there other cases I am unaware of?

I don't think this is specific to RDF or Atom.

1. Sam mentioned precedence rules (href and atom:href).

2. It's not clear how you'd pepper atom elements with attributes (ie do 
we spec that you must put your extra attribs in a namespace?).

3. it's not clear whether you're allowed to do 2 (because it's not clear 
whether the spec keys off from a spirit of entitlement or liberty).

4. it's not clear whether atom prefixed attributes are allowed or 
acceptable. Is it one or the other? Both?

So I'd conclude that the specification is silent on the matter of 
attribute prefixing doesn't make things less messy, it's somewhat messy 
already; specification just shines a light on that. Indicating digust 
doesn't make the sitaution better or worse, although an attitude along 
the lines of "how could I possibly care about this arcana" seems fine to me.

cheers
Bill

---

From: Sam Ruby <[email-masked]>
Date: Tue, 25 Jan 2005 10:07:05 -0500

> 1. Sam mentioned precedence rules (href and atom:href).

atom:href is not part of the specification.

> we spec that you must put your extra attribs in a namespace?).

This should be made clearer.  What I would suggest (for the spec'ed XML 
serialization) is that adding attributes to atom elements is OK if and 
only if they are in a namespace other than "" or atom's.

> whether the spec keys off from a spirit of entitlement or liberty).

The spirit should be "must ignore".

> acceptable. Is it one or the other? Both?

Such attributes are not equivalent to the spec'ed attributes, so the 
expectation would be that they would be ignored.  I would support making 
this clearer per my comment to #2.

> the lines of "how could I possibly care about this arcana" seems fine to 

I only see some small tweaks required (as perhaps some education on 
attributes to go into a separate document).

- Sam Ruby

---

From: Bill de hÓra <[email-masked]>
Date: Tue, 25 Jan 2005 15:16:39 +0000

[cc'd to Robert]

> atom:href is not part of the specification.

That should be made clearer ;)

>> 2. It's not clear how you'd pepper atom elements with attributes (ie 
>> do we spec that you must put your extra attribs in a namespace?).
>  

+1. It seems like all that need to be done is to constrain how others 
add/extend into atom elements. Rob says a 05 is looming; given that and 
15 paces in play, should I wait until the 05 draft before suggesting text?

cheers
Bill

---

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

> the lines of "how could I possibly care about this arcana" seems fine to me.

Quite. But I don't think "how could I possibly care" is a good
justification for a -1.

If it is, fine, I'll just sign our cats up to the list, they don't
care either but are generally positive about things, so expect +1s...

Cheers,
Danny.

-- 

http://dannyayers.com

---

From: Asbjørn Ulsberg <[email-masked]>
Date: Tue, 25 Jan 2005 20:10:47 +0100

> only if they are in a namespace other than "" or atom's.

+1. Some language describing this should go into the specification. I hope  
we don't need a pace to cover that.

> this clearer per my comment to #2.

I agree. I also think we should keep «Atom attributes» (although not in  
the Atom namespace) unprefixed and un-namespaced to have the format look  
cleaner and more readable. That doesn't mean that '"":href' is the same as  
'atom:href', though.

Thus, I'm -1 on this pace, but +1 on making the spec clearer about these  
issues.

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

---

From: Bill de hÓra <[email-masked]>
Date: Tue, 25 Jan 2005 23:12:49 +0000

> Quite. But I don't think "how could I possibly care" is a good

I can live with it, with respect to a deadline and 15 paces. This is not
  the most important thing we could be looking at and one or two
sentences about how extensions should proceed can cover it off.

cheers
Bill

---

From: David Powell <[email-masked]>
Date: Wed, 26 Jan 2005 01:20:58 +0000

> PaceAttributesNamespace

I'm -1 on this. It seems to be authorising a RDF users to do a
transform on Atom Syntax in order to make it more RDF/XML-like.

If RDF users have to transform the content in order to interpret it as
RDF/XML (which they do), then they might as well transform it to a
decent RDF model which properly models the entities and properties
involved in the feed.  We don't need the format spec to authorize RDF
users to do this - they can just do it.

I don't think that tweaking an Atom document and interpreting it as
RDF/XML is going to produce a sensible RDF model.

There are also a number of technical problems:

 * The attribute namespace prefixing problem solved by this Pace

 * atom:author defaulting won't be modelled sensibly

 * The xml:lang and xml:base context won't be preserved by Text
   constructs and Extensions if they are modelled as RDF XML Literals.[1]

 * parseType="Resource" / parseType="Literal" needs to be assumed in
   certain places.

If we try to solve all of these problems, then we are going to have to
do a fairly complicated transformation that needs to be applied to
produce a what could end up a quirky sub-optimal model.

I'd rather us make sure that we have designed the format spec well
enough that it has a clear model for core elements and extensions.

Then the RDFers can come up with a clear well-designed RDF vocabulary
for Atom and a mapping from Atom format to RDF (via XSLT?).

I've just posted this as an informal proposal on the Wiki suggesting
that we let an RDF mapping should be defined outside of the format
specification, and that we should avoid making this impossible:

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

[1] http://www.w3.org/TR/2002/REC-xml-exc-c14n-20020718/#sec-Limitations

-- 
Dave

---

From: Henry Story <[email-masked]>
Date: Wed, 26 Jan 2005 08:43:06 +0100

Thanks David. I take it that you would be +1 if you thought the 
AtomAsRDF
project were feasible. Thanks a lot for the list of problems you think
this entails.

These need to be considered one by one.

> users to do this - they can just do it.

The purpose of AtomAsRDF is not so much to allow RDFers to have an easy
life (we are purposely seeking minimal changes to Atom, and maximum hoop
jumping for RDFers), but to make it easy to specify a clear and powerful
extension framework for Atom. If AtomAsRDF succeeds then we can simply
build on the extensibility of RDF. Extensibility is part of the Atom 
Working
group charter.

> RDF/XML is going to produce a sensible RDF model.

I need skeptics to help me test my ideas. But the benefits are too big 
to
not at least try this out. For one it could give Atom the claim to have
dealt with the RSS wars, thereby getting the following perhaps of both 
camps.

>  * The attribute namespace prefixing problem solved by this Pace

ok. done. Thanks. So it is +1 for the AttributesNamespace Pace ;-)

>  * atom:author defaulting won't be modelled sensibly

Very simple to change. And it is something that should be altered
anyway. Paul Hoffman has said so on the 4th January. Dan Brickley
just suggested that we need to find a way to state that
the email and perhaps uri elements be inverse functional. Currently
they are defined to be functional.

I will open a pace for this. The nice thing is that this is an
improvement that AtomAsRDF does not absolutely need, but that would
improve atom anyway.

>    constructs and Extensions if they are modelled as RDF XML 

This is a more serious claim. It needs to be looked into.

>  * parseType="Resource" / parseType="Literal" needs to be assumed in

That is not a difficult problem to solve. It can be placed in the DTD.
And be specified easily to be a hidden element in Atom.

> produce a what could end up a quirky sub-optimal model.

As I mentioned above the point is to make it easy to explain how atom
can be extended in a well structured manner. If RDFers have to jump 
through
hoops that is less of a problem. It may be a problem for Atom only so 
far as
this may suggest to Atomers that they have designed something
unnecessarily complex.

> for Atom and a mapping from Atom format to RDF (via XSLT?).

As far as the extensibility problem is concerned you would also need the
following:

given an RDF graph mapped to by your xslt transformed rdf, you would 
need
to specify how this graph can be extended in some way and then mapped 
back
to produce an clearly understandable version of extended Atom, that 
should
easily be transformable back into your model.

And I think that AtomAsRDF is a hell of a lot simpler road to travel 
than that.

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

I am trying the optimum strategy here. I think we should pursue this as 
far
as we can, if not all other strategies will be left as options. In any 
case
we are both moving in the same direction.

Henry Story
http://bblfish.net/

> [1] 
> http://www.w3.org/TR/2002/REC-xml-exc-c14n-20020718/#sec-Limitations
>
> -- 
> Dave
>

---

From: Danny Ayers <[email-masked]>
Date: Wed, 26 Jan 2005 11:32:26 +0100

> transform on Atom Syntax in order to make it more RDF/XML-like.

That's really orthogonal from the intention.

> users to do this - they can just do it.

True. But that "decent RDF model" will presumably be based on the
model implicit in the Atom spec. But there are points which can't be
carried from the spec as it stands into the world of resources at
large - the unqualified attributes.

> RDF/XML is going to produce a sensible RDF model.

That isn't really the intention, although there's no reason to make
the transformation any more complicated than it needs to be.

>  * parseType="Resource" / parseType="Literal" needs to be assumed in

Only the first is covered by this Pace.

> produce a what could end up a quirky sub-optimal model.

This is extrapolating a lot way from the proposal.

> enough that it has a clear model for core elements and extensions.

Yes, exactly.

> for Atom and a mapping from Atom format to RDF (via XSLT?).

There is a clear mapping of construct *names* from Atom to the RDF
world (the element names have URIs), but the unprefixed attributes
don't have URIs.

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

"Interpreting Atom syntax as RDF/XML is not possible without applying
transformations. "

I don't care about Atom syntax as RDF/XML per se, what I'm interested
in is Atom as RDF.

" Atom should define a consistent model for its core elements."

Exactly. What it currently lacks is unambiguous names for the
attributes outside of document instances.

Cheers,
Danny.

-- 

http://dannyayers.com