Subject: Referencing entry URI from content

From: Danny Ayers <[email-masked]>
Date: Fri, 22 Oct 2004 13:27:26 +0200

Just a thought -

If "It's the Entries, Stupid!", then it doesn't seem unreasonable for
the content to be able to carry a reference back to the entry. Is
there any way this could work?

Just to clarify what I mean, here's a strawman with the kindling
pre-lit - the entry has a URI, so presumably that would be an
appropriate hook:

<entry>
   <id>http://example.org</id>
   <content type="application/xml">
        <foo source="$id" />
   </content>
</entry>

When passed to subsequent processing, the content would appear as:

<foo source="http://example.org" />

The templating kind of approach here suggests one kind of situation in
which it might be useful, another would be in a possible approach to
extensibility, in which characteristics of the entry could be
described within the content, by reference back to the entry id.

Relative XPaths may be a possible approach, only that seems even more
fragile than the technique above.

I'm not really suggesting this is a requirement, just that if it were
possible to achieve painlessly, it could well be useful.

Cheers,
Danny.

-- 

http://dannyayers.com

---

From: Asbjørn Ulsberg <[email-masked]>
Date: Mon, 25 Oct 2004 10:26:04 +0200

> there any way this could work?

I'm not sure why this would be useful.. Is it because the inner content of  
atom:entry can be plucked out of the atom:entry and thus needs to say  
which atom:id that was its parent?

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

---

From: Danny Ayers <[email-masked]>
Date: Mon, 25 Oct 2004 14:07:52 +0200

> which atom:id that was its parent?

Yep,  it would enable the content to talk about it's container entry.
Say the content was a full XHTML document, the <body> would contain
the renderable content, the <head> would contain (additional)
metadata. One significant piece of metadata would be the entry from
whence it came.

The scenario isn't unlike the fairly common RDF/XML idiom of using
rdf:about="" to refer to the container resource/document (e.g.
foaf:PersonlProfileDocument). If the payload of an Atom entry happened
to be RDF/XML you might wish to refer to the entry id rather than the
feed URI. This /could/ be embedded at the same time the <id> element
is generated/inserted but it feels like that would mean tight system
coupling at the process level rather than loose coupling at the data
level.
I'm still not sure...  

Cheers,
Danny.

-- 

http://dannyayers.com

---

From: Dare Obasanjo <[email-masked]>
Date: Mon, 25 Oct 2004 05:35:19 -0700 (PDT)

> > > there any way this could work?

It may not seem unreasonable but it doesn't seem
terribly useful either. 
 
> Yep,  it would enable the content to talk about it's

I can't think of a scenario where this would be
practically useful. Can you provide an example of how
one would use this or why they would? 

=====
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: Mon, 25 Oct 2004 18:17:04 +0200

> one would use this or why they would?

Couple of posts back:

To qualify all that, from my initial post:
I'm not really suggesting this is a requirement, just that if it were
possible to achieve painlessly, it could well be useful.

Cheers,
Danny.

-- 

http://dannyayers.com