[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message]

Re: Partyin' like it's 1999

  • To: Jeff Rafter <lists@j...>
  • Subject: Re: Partyin' like it's 1999
  • From: Eric Hanson <elh@c...>
  • Date: Tue, 2 Nov 2004 00:04:45 +0000
  • Cc: xml-dev@l...
  • In-reply-to: <41867D2D.9050402@j...>; from lists@j... on Mon, Nov 01, 2004 at 10:15:09AM -0800
  • References: <15725CF6AFE2F34DB8A5B4770B7334EE07206889@h...> <20041028210212.A27335@a...> <41819419.6000707@m...> <20041029040017.A79613@a...> <41867D2D.9050402@j...>
  • User-agent: Mutt/1.2i

distributed database trusted feed
Jeff Rafter (lists@j...) wrote:
> >>Umm, RDDL?
> > 
> > RDDL is great, and I think it would be a fundamental part of
> > such an infrastructure.  But I don't think it is or was ever
> > intended to be a mechanism for third parties to associate
> > resources with a datatype in a universal fashion.  RDDL alone is
> > a closed environment where resource associations are under the
> > control of whoever owns the namespace.  RDDL is authoritative,
> > first party info -- but that's just part of the equation. 
> 
> Clearly I am missing the problem here. It strikes me that you can do 
> exactly what you want to do with RDDL. If you are adding an extension to 
> an RSS document that is namespaced-- make sure you place an RDDL 
> document at the end of the namespace. If you are implementing someone 
> else's extension in your RSS document use their namespace (that points 
> to an RDDL document). At the end, the RDDL document will describe 
> plugins, rendering algorithms or what-have-you that can be employed by 
> many or by specific aggregators (e.g. a style sheet to present the feed 
> information in a customized fashion).
> 
> Then when Sally User subscribes to your feed in her favorite aggregator 
> it encounters a namespace it does not recognize *attempts* to resolve 
> the namespace hoping for something useful and finds the RDDL. Then it 
> finds that there is a stylesheet it could use to display your 
> extension-- prompts Sally to see if she really wants that and installs 
> and executes it.
> 
> I don't understand how this is fundamentally different than setting up a 
> name server for a DNS lookup-- apart from the propagation of the entry 
> throughout the distributed database. Regardless though I think the 
> distributed database is intended to solve a different problem-- I think 
> it is acceptable to have the RDDL entry maintained at one location-- if 
> it fails, then it is likely that the associated resources would fail.
> 
> The remaining problem is when I want to write a stylesheet for someone 
> else's namespace. How does one discover it? 

Yeah, that's it exactly.

> In this case I see what you 
> are driving at but would still shy away from a distributed database. It 
> seems like you might accomplish much of what you want simply by adding 
> in additional RDDL pointers:
> 
> <html xmlns="http://www.w3.org/1999/xhtml" 
> xmlns:rddl="http://www.rddl.org" 
> rddl:see-also="http://www.w3.org/1999/xhtml 
> http://www.example.org/my-xhtml-extensions"/>
> 
> In any event I don't think I would want random people making assertions 
> about any namespace they want. I wouldn't want to load up my aggregator 
> and have 7000 popups for extensions/plugins to RSS... requiring it to be 
> embedded in the document at least gives you a source for any malicious 
> plugins. For more broad range applications the aggregator itself can 
> host a site for extensions (a la Firefox or Thunderbird).

By default most apps should probably use the authoritative
resources, as described by RDDL or some other authoritative data
source.*  Beyond this, linking from RDDL to other "recommended"
third-party resources, that's cool too.

But don't you think it'd be useful to have some mechanism for
discovering third-party resources?  Otherwise the namespace
owner has 100% control over what resources can be discovered
about their data format.  I can see lots of scenarious where
this is less than desirable.  

Say I invent a SVG aggregator.  Say there are 10 or 20
extensions that are in prevelant use out there, and I want to
add support for them by writing transformations to SVG.  If all
we have is RDDL, I have to go around contacting the "owners" of
all these namespaces and try to convince them to add my
resources to their RDDL document.

First, they may not want to add my cool new resource.  Maybe
they're a company that sees my SVG browser as competition.
Maybe they're just lazy.  Maybe they think SVG is a lousy
technology.  Etc.

Also, trust.  Namespace owners don't know me, nor do they have
any reason to label my resources as trusted or recommended would
be really be going out on a limb for them.  Especially
considering I could pull the old bait and switch, and replace
the SVG transformation to transform the item into an ad for
viagra or something.  

Third party resources need to be treated differently then
authoritative or recommended ones, that's for sure, but I think
they need to be supported in some fashion.  

Eric

* WebDAV's dead properties metadata?

PURCHASE STYLUS STUDIO ONLINE TODAY!

Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced!

Buy Stylus Studio Now

Download The World's Best XML IDE!

Accelerate XML development with our award-winning XML IDE - Download a free trial today!

Don't miss another message! Subscribe to this list today.
Email
First Name
Last Name
Company
Subscribe in XML format
RSS 2.0
Atom 0.3
 

Stylus Studio has published XML-DEV in RSS and ATOM formats, enabling users to easily subcribe to the list from their preferred news reader application.


Stylus Studio Sponsored Links are added links designed to provide related and additional information to the visitors of this website. they were not included by the author in the initial post. To view the content without the Sponsor Links please click here.

Site Map | Privacy Policy | Terms of Use | Trademarks
Free Stylus Studio XML Training:
W3C Member
Stylus Studio® and DataDirect XQuery ™are products from DataDirect Technologies, is a registered trademark of Progress Software Corporation, in the U.S. and other countries. © 2004-2013 All Rights Reserved.