Ok, so I walked away from this for a few days then thought about it
again. Practically speaking, I don't really give a damn whether or not
it's a x:profile / or a link rel=profile / because folks who want
to do this type of thing will adapt to whatever the mechanism is. The
profile thing
On 10/22/05, James M Snell [EMAIL PROTECTED] wrote:
Hmm.. the more I think about this and the more we discuss it, the less I
think I like link[rel=profile]. While the URI of the profile
reference should be dereferenceable, most of the time the profile value
is going to be used as an
On Oct 23, 2005, at 6:45 PM, James Holderness wrote:
James M Snell wrote:
1. Can a profile element appear in an atom:feed/atom:source? If
so, what does it mean? I think it should with the caveat that the
profile attribute should only impact the feed and should not
reflect on the
Joe Gregorio wrote:
On 10/22/05, James M Snell [EMAIL PROTECTED] wrote:
Hmm.. the more I think about this and the more we discuss it, the less I
think I like link[rel=profile]. While the URI of the profile
reference should be dereferenceable, most of the time the profile value
is going to
On 10/24/05, James M Snell [EMAIL PROTECTED] wrote:
Joe Gregorio wrote:
I would prefer a [EMAIL PROTECTED]'profile' as it provides a nice symmetry
with (X)HTML, in particular the microformat use of such
link elements to point at XMDP documents[1].
-joe
[1] http://www.gmpg.org/xmdp/
At 12:45 PM 2005-10-24, Joe Gregorio wrote:
On 10/24/05, James M Snell [EMAIL PROTECTED] wrote:
Joe Gregorio wrote:
I would prefer a [EMAIL PROTECTED]'profile' as it provides a nice symmetry
with (X)HTML, in particular the microformat use of such
link elements to point at XMDP
James M Snell wrote:
1. Can a profile element appear in an atom:feed/atom:source? If so, what
does it mean? I think it should with the caveat that the profile attribute
should only impact the feed and should not reflect on the individual
entries within that feed.
I can't see any particular
more as an identifier). Strictly speaking,
dereferenceable profile links should probably use the atom:link element
but there is no hard requirement that says a profile element wouldn't
also work.
Using atom:link strikes me as tag abuse [1]. But that's what
microformats tend to do (use
be a
dereferencable link to a profile document that describes the profile
but, for the most part, clients will likely only rarely ever dereference
it (using the href more as an identifier). Strictly speaking,
dereferenceable profile links should probably use the atom:link element
but there is no hard requirement
should be a
dereferencable link to a profile document that describes the profile
but, for the most part, clients will likely only rarely ever dereference
it (using the href more as an identifier). Strictly speaking,
dereferenceable profile links should probably use the atom:link element
Bill de hÓra wrote:
(taking off my markup hat)
If someone said to me you can check an entry's profile via an
atom:link/@rel='profile' I would say 'ok, that's fine' (soon followed by
'what should I do if all the other metadata isn't there?'). If it's
truly abuse the registrar can trap it and
James Holderness wrote:
James M Snell wrote:
Hmm.. the more I think about this and the more we discuss it, the
less I think I like link[rel=profile]. While the URI of the
profile reference should be dereferenceable, most of the time the
profile value is going to be used as an identifier.
James M Snell wrote:
James Holderness wrote:
James M Snell wrote:
Hmm.. the more I think about this and the more we discuss it, the
less I think I like link[rel=profile]. While the URI of the
profile reference should be dereferenceable, most of the time the
profile value is going to
On 10/22/05, James M Snell [EMAIL PROTECTED] wrote:
Ok, x:profile ref={uri} / works very well I think.
ref? Can we please ditch the pseudo-RDF garbage? Leave an idea alone
for two seconds...
Robert Sayre
jokingRobert: Did you have to get special training to be so grumpy? Or
does it just come naturally?/joking
I actually meant to use href, but after reading the other note, I had
ref stuck in my head and didn't catch my error.
What I wanted to say was
x:profile href={uri} /
profileElement
could be anything really, but generally describe
the kinds of metadata and content that the entry is expected to
contain. For instance, the podcast profile could indicate that the
entry should contain at least one link[rel=enclosure].
Any single entry may contain multiple profile links. It is up
contain multiple profile links. It is up to the
feed consumer to make sense of it all. If an entry specifies
contradictory profiles, it's up to the consumer to sort it out.
The profile documents should be dereferenceable.
Thoughts? Gripes? Praise?
I think you're proposing to enable a kind
should be a
dereferencable link to a profile document that describes the profile
but, for the most part, clients will likely only rarely ever dereference
it (using the href more as an identifier). Strictly speaking,
dereferenceable profile links should probably use the atom:link element
I'm not sure if I've understood you correctly, but if this could be used as
a hint to the aggregator on how best to process/display the feed then I
think it's a great idea.
For example, knowing that a feed was a collection of images (e.g. a Flickr
feed) would enable the aggregator to
James Holderness wrote:
I'm not sure if I've understood you correctly, but if this could be
used as a hint to the aggregator on how best to process/display the
feed then I think it's a great idea.
Yes, that's exactly what it's for.
For example, knowing that a feed was a collection of
20 matches
Mail list logo
