Re: [RSS2-Support] Re: RSS 2.0 amendments process?
> >> I agree. But there is already a widely used alternative:Indeed, the only downside is the semantics behind dc:creator are not very well
> >> dc:creator. Even Jon Udell is using it.
> > The problem is that's part of the RSS 1.0 RDF spec, not the 2.0 spec.
> Not at all. dc:creator is a Dublin Core element, has nothing to do with
> RSS 1.0 or even RDF. It's perfectly fine as an extension for RSS 2.0.
defined. It can be anything in that string. And I've seen quite a range in
processing the data via Syndic8.
Thus some RDF folks are beginning use <foaf:maker
rdf:resource="url/of/author/foaf.rdf"/> instead. The same sort of idea can
easily be applied to any XML application. That it's commonly used in something
like RSS-1.0 doesn't mean it's not useful elsewhere.
The advantage of using stuff in the RSS-1.0 (RDF) fashion is one of
consistency. The model's pretty robust once you get your head wrapped around
it's nuances. Making use of resource URLs opens the door to a whole bunch of
ideas. But alas that's mired in a quagmire of FUD so I suppose we shouldn't go
there (at least not on /this/ list)
I'd certainly welcome better efforts to structure author or for that matter
people info in general.
Like others here I don't see why yet another style has to be invented for
contact info. There's been a ton of useful research done in other efforts. Why
reinvent what they've done? The downsides of reinvention are many. For one, it
ends up pissing off the people that did all the hard work (just to see it
imitated; often poorly). It also adds yet another layer of processing
applications are expected to perform. For stuff like contact info there's such
a huge body of research that's been done it REALLY seems sort of dumb to
reinvent it here...
But that's just my well-informed and battle-scarred opinion, of course.
- Dear Mr "him",
On Friday, Oct 3, 2003, at 20:38 Europe/Amsterdam, houghtoa wrote:
> You missed the point, but worst, are reckless about bandwidth issues.
You are presuming a very narrow usage pattern. And what's wrong with http
> "Adverse" is rather strong.
"Adverse" is to the point. If you use any type of aggregate format you will need a two
steps process: get a "bill of materials". Then get the content. It would be very
unfortunate if to get the BOM you need to get the entire content.
> Surely this was sarcasm. How can you comment that it's just like mail attachments.
Surely it was. I happen to have some exposure to the inner working of email:
This doesn't make me an authority on the matter though.
> You missed the point again.
Nope. I got your point. But perhaps you didn't get mine. Which is ok. We could agree
> As someone else pointed out, if you don't want to use an archiving mechanism
> then use multiple items, yet another solution for working *within*
> the current specification.
Ok. Let me illustrate my "circumstances" more concretely. This will most likely require
a great leap of faith on your side, but I'm sure you can manage.
Lets assume that I want to publish a RSS item regarding a forthcoming meeting. The
meeting is about some random corporate activities. I also spent some time preparing
supporting materials for this forthcoming event: a document describing the agenda, a
spreadsheet with some nice pie charts and a presentation outline. Those materials are
related to this event. They are not random artifacts. Now, if I want to attach this
material with my RSS item, what do I do?
(1) I use one enclosure and package all the materials in some sort of archive.
Workable for sure. But cumbersome. And I'm loosing the information about what's in
the archive. Instead of a Word document, an Excel spreadsheet and a PowerPoint
presentation, I now have an amorphous blob. Sure, I could dig into this archive to
retrieve its content. But then I will need to make the assumption that this archive is
just a wrapper for its content. And not the content itself. How do I distinguish
between an enclosure which points to an archive and an enclosure which point to a
wrapper? This introduce ambiguity of intend.
(2) I create multiple RSS item for this event: perhaps one for the event itself. And one
for each document. Something like: here is the event. And here is a document. And
here is a spreadsheet. And here is a presentation. Workable for sure. But I lose the
"unity of action". Instead of having one RSS item with some attached materials, I now
have four different items with nothing to link them together. Sounds like a dead end
(3) I create one RSS item with multiple enclosures. End of the story. Unity of action.
Why don't you also apply your phenomenal analytical power to the other three topics
at hand? Would love to hear your personal take on them.