Hi,
There's been mention of RDDL a few times on this list (mainly wrt to
spec/module documentation). I've written an RDDL tutorial [1] which
might prove useful/interesting for those of you wanting to learn more.
I'd like to formally propose that we adopt RDDL as the documentation
standard for RSS 1.0, and all associated modules.
It would be relatively trivial to migrate existing documentation over to
RDDL (its in XHTML now currently IIRC). If possible I'd also like all
RSS 1.0 modules to be documented in RDDL as a mandatory requirement.
RDDL ("Riddle") will give us a nice framework into which we can combine
documentation and resources. I think there may be scope for defining
some additional RDDL natures/purposes for RSS specific uses, e.g.
a nature for an RSS feed, RSS 0.9X <-> RSS 1.0 up/down convertors, etc.
As I note in the tutorial there's some interesting scope for chaining
XSLT transformations by traversing RDDL documents. I believe this
would work well in a content syndication arena as there are currently
several popular formats.
Cheers and comments very welcome!,
L.
[1]. http://www.xml.com/pub/a/2001/02/28/rddl.html
--
Leigh Dodds, Systems Architect | "Pluralitas non est ponenda
http://weblogs.userland.com/eclectic | sine necessitate"
http://www.xml.com/pub/xmldeviant | -- William of Ockham
Leigh Dodds writes:
> I'd like to formally propose that we adopt RDDL as the documentation
> standard for RSS 1.0, and all associated modules.
>
> It would be relatively trivial to migrate existing documentation over to
> RDDL (its in XHTML now currently IIRC). If possible I'd also like all
> RSS 1.0 modules to be documented in RDDL as a mandatory requirement.
I think this is a good suggestion. I didn't follow the RDDL
development on XML-Dev, but I gave the spec a thorough read during my
flight to New York yesterday and I couldn't find anywhere obvious I
could shoot holes in it (and I shoot holes in everything) -- it's
trivially simple but extremely powerful. Jonathan Borden, Tim Bray,
and the others did a great job on it.
All the best,
David
--
David Megginson david@...
http://www.megginson.com/
> I'd like to formally propose that we adopt RDDL as the documentation
> standard for RSS 1.0, and all associated modules.
Sounds good to me. It'd be nice if parsers could start to accept RDDL
where appropriate... but because it can encompass almost any form of
schemata or definition langauge, it has a wide scope to cover. Still,
I'd like to see it used on XSV for a start, and perhaps in SW
processors in the near future.
Of course, for all you cynicists out there, I only support this
because RDDL is based on XHTML Basic :-)
--
Kindest Regards,
Sean B. Palmer
@prefix : <http://webns.net/roughterms/> .
:Sean :hasHomepage <http://infomesh.net/sbp/> .
Leigh Dodds wrote:
>
> Hi,
>
> There's been mention of RDDL a few times on this list (mainly wrt to
> spec/module documentation). I've written an RDDL tutorial [1] which
> might prove useful/interesting for those of you wanting to learn more.
>
> I'd like to formally propose that we adopt RDDL as the documentation
> standard for RSS 1.0, and all associated modules.
The taxo module has been written as RDDL :) ...
Eric
--
See you in Austin (Knowledge Technologies 2001)
http://www.gca.org/attend/2001_conferences/kt_2001/mon.htm
------------------------------------------------------------------------
Eric van der Vlist Dyomedea http://dyomedea.comhttp://xmlfr.orghttp://4xt.orghttp://ducotede.com
------------------------------------------------------------------------
In accordance with our procedures, the content module has been voted an
official module. The vote is at:
http://logicerror.com/rss-votes-content
Should the proposed content module be made an official module?
Yes: 3 WG (Aaron, Eric vdV, Leigh); 2 IG
No: 0
Abstain: 0
This poll closed on March 1, 2001.
Now the question becomes what do we do with it? First, Rael needs to make a
PURL for it, but see the next message for more.
--
Aaron Swartz <me@...>| my.info
<http://www.aaronsw.com> | <http://my.theinfo.org>
AIM: JediOfPi | ICQ: 33158237| the future of news, today
As RSS increases in popularity and utility, and as we begin to discover more
RSS 1.0-related things, I feel that it becomes more important than ever to
have a RDDL document at our namespace. This document would link to:
- Our specification (which should be given a PURL)
- Standard RSS Modules
- Schemas (XML schema, TREX, Schematron, RDF, etc.)
- Our mailing list
- RSS News Sites
- etc. (I'm sure others can be suggested)
An example RDDL document is at:
http://blogspace.com/rss/rddl-example
I'm sure others can suggest more URLs to add. It would go where the
specification currently is and the specification would be moved to it's own
URL (http://purl.org/rss/1.0/spec).
What do others think about this?
--
Aaron Swartz <me@...>| my.info
<http://www.aaronsw.com> | <http://my.theinfo.org>
AIM: JediOfPi | ICQ: 33158237| the future of news, today
The following rss-dev poll is now closed. Here are the
final results:
POLL QUESTION: WG Vote on moving the taxonomy module to
standard. See
http://groups.yahoo.com/group/rss-dev/me
ssage/1578 for details. *Vote is
restricted to WG members* *Vote will
conclude on 2001-3-03*
CHOICES AND RESULTS
- Yes, option 2 , 3 votes, 75.00%
- I abstain , 0 votes, 0.00%
- No (please share your reasons with rss-dev) , 0 votes, 0.00%
- Yes, as it is proposed , 1 votes, 25.00%
INDIVIDUAL VOTES
- Yes, option 2
- aswartz@...
- begeddov@...
- eisen@...
- I abstain
- No (please share your reasons with rss-dev)
- Yes, as it is proposed
- vdv@...
For more information about this group, please visit
http://groups.yahoo.com/group/rss-dev
For help with Yahoo! Groups, please visit
http://help.yahoo.com/help/us/groups/
For what it's worth, I think David really hits the mark with his
comment that:
> That said, the RSS 1.0 WG is now busying itself creating new add-on
> modules, just like the XHTML people, and that's a BAD move: people
> will (incorrectly) think that they need to learn and support all the
> modules to support RSS, just as people think that they need to learn
> and support XSL, XML-Schemas, XLink, XInclude, etc. etc. etc. to
> support XML. I agree with the Kent Beck and the other XP people on
> this point -- never add new functionality in anticipation, but wait
> until people are screaming so loudly that you can no longer ignore
> them.
The recent activity in this group seems to be consisting of at most 3
people voting here and there. It might be a good idea to let RSS 1.0
grow, get more tools, and then see where the needs lie. That is very
much how the whole initiative to build a next-gen RSS in the first
place: RSS 0.91 was too frustrating and 'demanded' some action. The
modularity that RSS 1.0 has was designed so that no similar effort to
that needed for 0.91->1.0 would be required again. So it might be an
idea to let things grow a while, and then standardize common usages into
the approved modules.
-- Edd
----- Forwarded message from David Megginson <david@...> -----
From: David Megginson <david@...>
Subject: RSS 1.0 vs. RSS 0.9*
To: "XML-Dev (E-mail)" <xml-dev@...>
List-Owner: <mailto:xml-dev-help@...>
List-Post: <mailto:xml-dev@...>
List-Subscribe: <mailto:xml-dev-request@...?body=subscribe>
List-Unsubscribe: <mailto:xml-dev-request@...?body=unsubscribe>
List-Archive: <http://lists.xml.org/archives/xml-dev>
List-Help: <http://lists.xml.org/doc/email-manage.html>,
<mailto:xml-dev-request@...?body=help>
Matt Sergeant writes:
[in response to Dave Winer writing on RSS 0.92]
> All in all, it gains most people nothing. I for one have moved on
> to RSS 1.0, which by the use of namespaces has allowed me to build
> an entire slashdot-like web site around the format, using standard
> vocabularies. When I need an author on each item, I use dc:creator
> from the Dublin Core. When I need a date, I can also use Dublin
> Core. For rich descriptions I can use dc:description with an
> xhtml-basic content. For my purposes, RSS 1.0 rocks. Note that none
> of these additions required me to write a new spec.
I agree with Matt. RSS 0.9* was simple enough to get people hooked on
a particular kind of information exchange (pretty-much headlines and
links) and was one of the greatest XML success stories, but it
wouldn't scale for other kinds of syndication. RSS 1.0 is complicated
enough that it might scare people away, but it will scale better.
Personally, I tend to err on the side of simplicity, but the proof is
in the implementations: the number of RSS 1.0 feeds (both converted by
a middle party or encoded by the source) is multiplying rapidly. I
have a small selection of RSS 1.0 feeds listed at
http://www.xmlnews.org/RSS/content.html
including feeds from ITN and Reuters Health, but there are many, many
more out there, and new ones are appearing regularly. Obviously, the
extra complexity in RSS 1.0 hasn't been enough to scare away
implementors, and the RSS 1.0 WG has hit a sweet spot between
simplicity and functionality. Kudos.
Dave (Winer), I shared some of your reservations about RSS 1.0 at the
start, but given the proof of RSS 1.0's rapid adoption rate, I'd
suggest that it's time now to bow out gracefully and admit you were
wrong. I had to do just that when I gave up my initial opposition to
XML and wrote AElfred, and again when I abandoned dozens of my initial
design proposals for SAX, and again when I gave up my opposition to
Namespaces and became an advocate, and so on and so on. Hell, I'm
probably wrong now, too (let's get that out of the way in advance this
time).
That said, the RSS 1.0 WG is now busying itself creating new add-on
modules, just like the XHTML people, and that's a BAD move: people
will (incorrectly) think that they need to learn and support all the
modules to support RSS, just as people think that they need to learn
and support XSL, XML-Schemas, XLink, XInclude, etc. etc. etc. to
support XML. I agree with the Kent Beck and the other XP people on
this point -- never add new functionality in anticipation, but wait
until people are screaming so loudly that you can no longer ignore
them.
All the best,
David
--
David Megginson david@...
http://www.megginson.com/
----- End forwarded message -----
For the record (and for those of you who are not on xml-dev), I forward
a recommandation from David Megginson worth thinking about !
Thanks David,
Eric
--
See you in Austin (Knowledge Technologies 2001)
http://www.gca.org/attend/2001_conferences/kt_2001/mon.htm
------------------------------------------------------------------------
Eric van der Vlist Dyomedea http://dyomedea.comhttp://xmlfr.orghttp://4xt.orghttp://ducotede.com
------------------------------------------------------------------------
Eric van der Vlist writes:
> Do you think that it is a matter of "presentation" and that big
> disclaimers that modules are only useful to perform "special" functions
> would be enough or do we have to imagine other safeguards ?
My recommendation would be not to create any official, WG-approved
modules at all for a while. Give RSS 1.0 a year to stabilise and
become more popular, while individual parties publish their own
(i.e. not WG-approved) modules. At the end of the year, find the the
minimum number of new features necessary to resolve (say) 50 percent
of complaints from users and reviewers, and standardise those (and
*only* those), ignoring any parts that do not actually resolve
complaints. Wait another year and repeat.
Basically, when someone asks "what is RSS?", you want to be able to
say "just read this short spec and you're done." Unfortunately,
success is a very addictive drug -- just look at the W3C, constantly
trying to recapture that first wonderful high from the success of XML
1.0 (I need to write ... I need to write just one more spec ... JUST
ONE MORE SPEC!!!). Don't go there. Just say no.
All the best,
David
--
David Megginson david@...
http://www.megginson.com/
Edd Dumbill <edd@...> wrote:
> The recent activity in this group seems to be consisting of at most 3
> people voting here and there. It might be a good idea to let RSS 1.0
> grow, get more tools, and then see where the needs lie.
I agree that David's comments should be considered and discussed here.
However, I don't know if this is such a good idea. There _are_ requests for
these modules -- people want to use them in the real world. Now I think we
all agree it's silly to tell them to not extend RSS -- isn't that why we
added modularization? It also seems silly for everyone to create their own
module that duplicates functionality. So I guess the question is what is the
problem, and what's the best way to solve it.
The problem seems to be the worry that we're making RSS too big and too
complicated. This is a valid concern, and in fact the one that led to
namespaces in the first place. The idea was that people would learn the
modules that they needed to use and ignore those they didn't.
It seems the solution to this is probably a publicity/site-management thing
more than anything else.
How do we manage it?
--
[ Aaron Swartz | me@... | http://www.aaronsw.com ]
On Sun, 4 Mar 2001, Aaron Swartz wrote:
> Edd Dumbill <edd@...> wrote:
>
> > The recent activity in this group seems to be consisting of at most 3
> > people voting here and there. It might be a good idea to let RSS 1.0
> > grow, get more tools, and then see where the needs lie.
>
> I agree that David's comments should be considered and discussed here.
> However, I don't know if this is such a good idea. There _are_ requests for
> these modules -- people want to use them in the real world. Now I think we
> all agree it's silly to tell them to not extend RSS -- isn't that why we
> added modularization? It also seems silly for everyone to create their own
> module that duplicates functionality. So I guess the question is what is the
> problem, and what's the best way to solve it.
OF course experimenting with a new module is different from adding a new
module to the specification. It might be reasonable to set a developer
'participation' threshold for a module, and require that sufficient people
be interested in (and working on) a module before it becomes a
standards-track development (so to speak).
> The problem seems to be the worry that we're making RSS too big and too
> complicated. This is a valid concern, and in fact the one that led to
> namespaces in the first place. The idea was that people would learn the
> modules that they needed to use and ignore those they didn't.
It would be useful to find out how many RSS 1.0 implementations actually
use proper RDF/namesapce processing of incoming (or outgoing) data. I
suspect that many implementations are just hacked up versions of RSS 0.91
processors. Obviously such implementations can't implement modules in any
meaningful way until the code is replaced.
It would also be nice to know what the broader group of RSS 1.0
users/developers want to do with RSS 1.0. Maybe it's time to revisit that
question? Pity there isn't a poll that lets you choose multiple options
....
> It seems the solution to this is probably a publicity/site-management thing
> more than anything else.
>
> How do we manage it?
I think Edd's point (that they are really only ~5 or so people actively
working -- or at least voting -- on this activity) is related to this -
issue it's hard to generate much publicity when there are so few people
actively developing and testing ideas. This small size also brings the
risk that development will head down a narrow path that satisfies only a
small group of developers/ users.
I don't mean by this to imply that things have gone badly -- I've been
very impressed by what this group has accomplished. I just want to
make sure that teh direction and energy isn't lost in moving on to the
next set of issues and ideas.
Ian
> --
> [ Aaron Swartz | me@... | http://www.aaronsw.com ]
>
>
> To unsubscribe from this group, send an email to:
> rss-dev-unsubscribe@egroups.com
>
>
>
> Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
>
>
>
Ian Graham <ian.graham@...> wrote:
> OF course experimenting with a new module is different from adding a new
> module to the specification.
But we do not add modules to the specification! We merely publish them as
"standard". The spec is not modified when a module is added, and clearly
states that the only modules "in-the-box" with RSS 1.0 are Syndication and
Dublin Core.
> It might be reasonable to set a developer
> 'participation' threshold for a module, and require that sufficient people
> be interested in (and working on) a module before it becomes a
> standards-track development (so to speak).
Hmm, sort of like Candidate Rec in W3C or two interoperable implementations
in IETF? That might be interesting. Perhaps we should have a "Candidate
Rec"-style stage for Modules. Thoughts?
> It would also be nice to know what the broader group of RSS 1.0
> users/developers want to do with RSS 1.0. Maybe it's time to revisit that
> question? Pity there isn't a poll that lets you choose multiple options
If anyone wants to do something with RSS, please get on the list and start
doing it! ;-)
Thanks for your help, Ian -- we're all trying to sort things out,
--
[ Aaron Swartz | me@... | http://www.aaronsw.com ]
Sunday, March 04, 2001, 2:05:40 PM, you wrote:
AS> Ian Graham <ian.graham@...> wrote:
>> OF course experimenting with a new module is different from adding a new
>> module to the specification.
AS> But we do not add modules to the specification! We merely publish them as
AS> "standard". The spec is not modified when a module is added, and clearly
AS> states that the only modules "in-the-box" with RSS 1.0 are Syndication and
AS> Dublin Core.
I think the concern is that these have been posted as 'standard'
without sufficient implementation practice in the real world. Of
course, it's just a matter of labelling, but having a waiting period
for people to test out these proposals wouldn't hurt. On the other
hand, I really don't think there is a large enough developer base of
RSS applications to get a fast enough turn around on these specs =(.
(witness the recent vote participation from the IG).
>> It would also be nice to know what the broader group of RSS 1.0
>> users/developers want to do with RSS 1.0. Maybe it's time to revisit that
>> question? Pity there isn't a poll that lets you choose multiple options
AS> If anyone wants to do something with RSS, please get on the list and start
AS> doing it! ;-)
I've been lurking the past month or so, just researching RSS and other
syndication formats. I am a developer with Intuit, and am implementing
an RSS viewer component for one of our Quicken-branded products -- this should
be out within two months or so, I'll announce it here for those that
are interested in checking it out). My concern is really for the
discovery of RSS channels. Currently we are just going to collect
channels that we think our user base would be interested in, and
provide our own directory service. It would be nice to have a
standardized directory format though to base this on. I have had a
look at OCS, but I was looking for something hiearchial.
I'll delurk here for a minute to say hi and perhaps contribute a bit to
the discussion. I've been providing an RSS 0.91 feed from my weblog for
a while now, and it gets plenty of hits, so I can see that the format is
useful. I'll be upgrading to 1.0 fairly soon, but I think I'm going to
write a client-side dedicated editor (Windows platform) first. I think
such a thing could be useful to those web page creators ("developers" is
too strong a word) who use tools like FrontPage -- right now, I suspect,
the bar for those folks to create an RSS 1.0 file is too high to get
over. Unless there's a client-side editor I'm not aware of, anyhow,
which is entirely possible.
Mike Gunderloy
> -----Original Message-----
> From: Ian Graham [mailto:ian.graham@...]
> It would also be nice to know what the broader group of RSS 1.0
> users/developers want to do with RSS 1.0.
To unsubscribe from this group, send an email to:
rss-dev-unsubscribe@egroups.com
Dion Loy <dion@...> wrote:
> I think the concern is that these have been posted as 'standard'
> without sufficient implementation practice in the real world. Of
> course, it's just a matter of labelling, but having a waiting period
> for people to test out these proposals wouldn't hurt. On the other
> hand, I really don't think there is a large enough developer base of
> RSS applications to get a fast enough turn around on these specs =(.
> (witness the recent vote participation from the IG).
So another vote for a Candidate Rec-type phase, and another complaint about
lack of implementers.
> I've been lurking the past month or so, just researching RSS and other
> syndication formats. I am a developer with Intuit, and am implementing
> an RSS viewer component for one of our Quicken-branded products -- this should
> be out within two months or so, I'll announce it here for those that
> are interested in checking it out).
Awesome! With RSS 1.0 support, right? That rocks!
> My concern is really for the
> discovery of RSS channels. Currently we are just going to collect
> channels that we think our user base would be interested in, and
> provide our own directory service. It would be nice to have a
> standardized directory format though to base this on. I have had a
> look at OCS, but I was looking for something hiearchial.
This seems like a great application for RSS modules... just combine the
non-existent threading/directory module with the non-existent OCS module and
you'd have the perfect solution. I think the problem we have is lack of
enthusiasm in developing modules, as well as implementation. Just about lack
of enthusiasm for everything. We have 180 members, but it seems that hardly
anyone contributes. And those that do do it very slowly... Oh well.
--
Aaron Swartz <me@...>| RSS Info
<http://www.aaronsw.com> | <http://www.blogspace.com/rss/>
AIM: JediOfPi | ICQ: 33158237| news and information on the RSS format
Mike Gunderloy <MikeG1@...> wrote:
> I'll delurk here for a minute to say hi and perhaps contribute a bit to
> the discussion. I've been providing an RSS 0.91 feed from my weblog for
> a while now, and it gets plenty of hits, so I can see that the format is
Could you send me the URL to the feed offlist?
> useful. I'll be upgrading to 1.0 fairly soon, but I think I'm going to
> write a client-side dedicated editor (Windows platform) first. I think
> such a thing could be useful to those web page creators ("developers" is
> too strong a word) who use tools like FrontPage -- right now, I suspect,
> the bar for those folks to create an RSS 1.0 file is too high to get
> over. Unless there's a client-side editor I'm not aware of, anyhow,
> which is entirely possible.
I don't think there is, and IMHO it's a tool that's sorely needed. Please
let us know when it comes out -- I feel that there's a lot of apps just
waiting to be released.
There's so much excitement behind RSS, but it feels like little action.
--
[ Aaron Swartz | me@... | http://www.aaronsw.com ]
Whenever I've got something with even half-assed functionality I'll post
a pointer here, and let folks tell me what it should REALLY do :)
Mike Gunderloy
> -----Original Message-----
> From: Aaron Swartz [mailto:aswartz@...]
>
Unless there's a client-side editor I'm not aware of, anyhow,
> > which is entirely possible.
>
> I don't think there is, and IMHO it's a tool that's sorely
> needed. Please
> let us know when it comes out
Aaron Swartz writes:
> This seems like a great application for RSS modules... just combine
> the non-existent threading/directory module with the non-existent
> OCS module and you'd have the perfect solution. I think the problem
> we have is lack of enthusiasm in developing modules, as well as
> implementation. Just about lack of enthusiasm for everything. We
> have 180 members, but it seems that hardly anyone contributes. And
> those that do do it very slowly... Oh well.
Give them time. The core members of your group have finished solving
only the specification problems for RSS 1.0 -- now you have to wait,
patiently, and give others the opportunity to start working on the
implementation, business, and user-community problems. People in the
wider world will use RSS 1.0 because it solves real problems or opens
up real opportunities for them, not simply because it's cool or new,
and they may need a year or two to stumble upon those solutions or
opportunities.
Users will find ways to use RSS 1.0 that you never expected (just as
Java ended up ruling the server side rather than the client side), but
they need time. Until then, your biggest goal should be to keep your
message simple. Don't confuse the users. New releases of anything
RSS 1.0-related are pure evil right now.
All the best,
David
--
David Megginson david@...
http://www.megginson.com/
> Aaron Swartz writes:
>
> > This seems like a great application for RSS modules... just combine
> > the non-existent threading/directory module with the non-existent
> > OCS module and you'd have the perfect solution. I think the problem
> > we have is lack of enthusiasm in developing modules, as well as
> > implementation. Just about lack of enthusiasm for everything. We
> > have 180 members, but it seems that hardly anyone contributes. And
> > those that do do it very slowly... Oh well.
>
> Give them time. The core members of your group have finished solving
> only the specification problems for RSS 1.0 -- now you have to wait,
> patiently, and give others the opportunity to start working on the
> implementation, business, and user-community problems. People in the
> wider world will use RSS 1.0 because it solves real problems or opens
> up real opportunities for them, not simply because it's cool or new,
> and they may need a year or two to stumble upon those solutions or
> opportunities.
>
> Users will find ways to use RSS 1.0 that you never expected (just as
> Java ended up ruling the server side rather than the client side), but
> they need time. Until then, your biggest goal should be to keep your
> message simple. Don't confuse the users. New releases of anything
> RSS 1.0-related are pure evil right now.
>
"Anything RSS 1.0 related" isn't pure evil. Software, tools, documents,
websites and feeds are great. Just no more specs!
Nick Lothian writes:
> > Users will find ways to use RSS 1.0 that you never expected (just as
> > Java ended up ruling the server side rather than the client side), but
> > they need time. Until then, your biggest goal should be to keep your
> > message simple. Don't confuse the users. New releases of anything
> > RSS 1.0-related are pure evil right now.
> >
>
> "Anything RSS 1.0 related" isn't pure evil. Software, tools, documents,
> websites and feeds are great. Just no more specs!
Right -- and specifically, no more specs from this group. There's
nothing wrong with other parties publishing their own specs to work
with RSS 1.0, since those aren't likely to cause confusion. Besides,
if I were to define a new set of RDF properties, why would I limit
their use to RSS in the first place?
All the best,
David
--
David Megginson david@...
http://www.megginson.com/
David Megginson <david@...> wrote:
> Besides, if I were to define a new set of RDF properties, why would I limit
> their use to RSS in the first place?
To clarify -
No one is "limiting" their use to RSS, we're merely providing an XML
representation so that they can be included in RSS. They can still be used
in any RDF just fine.
--
[ Aaron Swartz | me@... | http://www.aaronsw.com ]
> I agree that David's comments should be considered and discussed here.
> However, I don't know if this is such a good idea. There _are_
> requests for these modules -- people want to use them in the real world.
Now I think we
> all agree it's silly to tell them to not extend RSS -- isn't that why we
> added modularization? It also seems silly for everyone to create their own
> module that duplicates functionality. So I guess the question is
> what is the problem, and what's the best way to solve it.
One of the reasons (the main one?) to add modularization is to allow people
to
make extensions to RSS without having to get it 'officially approved'. We've
delivered
on that I think.
I also don't see any harm in people producing slightly different versions of
some modules - it gives chance for experimentation. Standardization has to
come after the innovation happens, when there's a need for it.
Cheers,
L.
David Megginson wrote:
>
> Nick Lothian writes:
>
> > > Users will find ways to use RSS 1.0 that you never expected (just as
> > > Java ended up ruling the server side rather than the client side), but
> > > they need time. Until then, your biggest goal should be to keep your
> > > message simple. Don't confuse the users. New releases of anything
> > > RSS 1.0-related are pure evil right now.
> > >
> >
> > "Anything RSS 1.0 related" isn't pure evil. Software, tools, documents,
> > websites and feeds are great. Just no more specs!
>
> Right -- and specifically, no more specs from this group. There's
> nothing wrong with other parties publishing their own specs to work
> with RSS 1.0, since those aren't likely to cause confusion.
This is a tough question.
On the other hand, if we end up with a number of different incompatible
modules to do the same things, it will also be confusing.
Maybe we need to find a place to keep track of these experiences with
RSS 1.0 (a la CPAN) ?
Eric (finding it very instructive to see that we are confronted to the
same types issues -with another scale, of course- than the W3C with XML)
> Besides,
> if I were to define a new set of RDF properties, why would I limit
> their use to RSS in the first place?
Of course, you don't have to, but defining them as RSS modules gives you
a format where RSS 1.0 core parsers can still find what they need.
Thanks
Eric
> All the best,
>
> David
>
> --
> David Megginson david@...
> http://www.megginson.com/
>
> To unsubscribe from this group, send an email to:
> rss-dev-unsubscribe@egroups.com
>
>
>
> Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
--
See you in Austin (Knowledge Technologies 2001)
http://www.gca.org/attend/2001_conferences/kt_2001/mon.htm
------------------------------------------------------------------------
Eric van der Vlist Dyomedea http://dyomedea.comhttp://xmlfr.orghttp://4xt.orghttp://ducotede.com
------------------------------------------------------------------------
Hi folks,
Coming a bit late to this, I can't find a succinct description of how the
taxo module should be applied. Can anyone here enlighten me a little?
Thanks,
Hugh
hpyle@...
hpyle@... <hpyle@...> wrote:
> Coming a bit late to this, I can't find a succinct description of how the
> taxo module should be applied. Can anyone here enlighten me a little?
It's to attach things (items, channels, topics) to categorizations. Here's
my new quick-start guide on how to use it:
http://logicerror.com/taxo-quick-start
(If people like these quick start guides, I'll do more.)
--
[ Aaron Swartz | me@... | http://www.aaronsw.com ]
Leigh Dodds wrote:
>
> Well seeing as I proposed this last week [1] I'm all for it! :)
>
> David Megginson [2], Eric [3] and Sean Palmer [4] were also for
> using RDDL as well.
>
> As we have several modules that can be interlinked we can
demonstrate
> the utility of a web of RDDL documents.
>
> We should also co-ordinate with Jonathan Borden, so that the
> RDDL document for RSS could be linked into a central RDDL document
> at rddl.org. This was mooted on XML-DEV [5, 6] a while back.
Yes and my apologies for being tardy getting this up, but i've been
working out a few natures and purposes to properly describe these
sorts of things. I've created a RDDL 'home' directory at:
http://www.rddl.org/home and would be happy to reference RDDL
documents for RSS when they are available.
Other possibilities are that if you develop lists of natures and
purposes related to RSS I'd also be happy to reference them from
within the RDDL natures and purposes documents.
-Jonathan
Thanks Aaron, that's exactly what I was looking for. One suggestion: the
opening paragraph should explain *why* you'd want to do this (ie. to give
aggregators and other RSS clients some hints on how to categorize your RSS
feed).
BTW, bugette in your listing: you have <dc:title>...</taxo:title>.
Is there any recommendation that the <taxo:link> target be a RDDL page, or
something equivalent to ensure a client application knows whether it can
parse the taxonomy (or display it nicely to the user, let the user browse a
tree, etc)?
-Hugh
hpyle@...
>> It's to attach things (items, channels, topics) to categorizations.
Here's
>> my new quick-start guide on how to use it:
>>
>> http://logicerror.com/taxo-quick-start
>>
>> (If people like these quick start guides, I'll do more.)
>>
>> --
>> [ Aaron Swartz | me@... | http://www.aaronsw.com ]
I'm forwarding this message on request.
I think we should revise the spec based on this advice. Its also
good news with regards to the RELAX grammars. Something that
we can add to our RDDL document!
Cheers,
L.
> -----Original Message-----
> From: mmurata@... [mailto:mmurata@...]
> Sent: 06 March 2001 07:43
> To: ldodds@...
> Cc: mmurata@...
> Subject: Comments on RSS
>
>
> Leigh,
>
> Could you forward this mail to the mailing list for RSS?
> Thanks in advance.
>
> Cheers,
>
> <warning>Speaking for himself only</warning>
>
> IBM Tokyo Research Lab / International University of Japan,
> Research Institute
> MURATA Makoto (FAMILY Given)
>
>
> --------------------------------------------------------------
>
> I had a quick look at RSS. I like it, and will create RELAX grammars
> for RSS. But I am writing this mail as a co-author of RFC 3023 (XML
> Media Types).
>
> >Mime Type
> >The current mime-type recommendation for an RSS 1.0 document is
> text/xml.
>
> Actually, text/xml is inappropriate for RSS. If casual users (who
> know nothing about XML) can read RSS documents with Notepad (no
> stylesheets, no fancy GUIs for XML), then text/xml is fine. Otherwise,
> use application/xml. The rest of this mail is quoted from RFC 3023.
>
> > If an XML document -- that is, the unprocessed, source XML document
> > -- is readable by casual users, text/xml is preferable to
> > application/xml. MIME user agents (and web user agents) that do not
> > have explicit support for text/xml will treat it as text/plain, for
> > example, by displaying the XML MIME entity as plain text.
> > Application/xml is preferable when the XML MIME entity is unreadable
> > by casual users. Similarly, text/xml-external-parsed-entity is
> > preferable when an external parsed entity is readable by casual
> > users, but application/xml-external-parsed-entity is preferable when
> > a plain text display is inappropriate.
> >
> > NOTE: Users are in general not used to text containing tags such
> > as <price>, and often find such tags quite disorienting or
> > annoying. If one is not sure, the conservative principle would
> > suggest using application/* instead of text/* so as not to put
> > information in front of users that they will quite likely not
> > understand.
> >
>
>
> Cheers,
>
> <warning>Speaking for himself only</warning>
>
> IBM Tokyo Research Lab / International University of Japan,
> Research Institute
> MURATA Makoto (FAMILY Given)
>
Section 5.5. of RSS RC1 indicates "There may be a minimum of one and
a maximum of fifteen items per RSS document."
Why the min of 1 ?
Scenario:
Using channel management software, user creates a channel.
Over time, user adds and deletes items from channel.
Periodically the number of items in the channel goes to 0. ( However
the user does not want to delete the channel definition or revoke the
availability of the channel - the condition is temporary. )
So, in the <channel> element why not allow the <items> sequence to be
empty in which case the allowed range of items in the RSS document
would be from 0 to 15 ?
Thanks, Pete
Send Email
