[
Lists Home |
Date Index |
Thread Index
]
Danny Ayers (danny666@virgilio.it) wrote:
> This is potentially a very powerful idea. The extensibility of
> XML+namespaces is pretty intangible - it's like calling a bucket
> extensible because you can put anything in it. RDF/XML offers more
> realizable extensibility thanks to the model behind the syntax providing
> at least partial understanding. But to enable full understanding in a
> pluggable fashion - that'd be pretty cool.
Thanks, seems like it could be pretty interesting.
At the risk of over-generalizing, the concept could be extended
beyond UI to just a general map of how to handle XML in an
arbitrary context.
> For a UI there is already XUL which on platforms that support it (i.e.
> Mozilla) could provide such dynamic configuration of interpretation on
> the basis of a URI (the namespace).
>
> RDDL would appear to provide a large part of what's needed, although
> 'purpose' will need further qualification to map between the application
> and the desired processing. What a browser does with an XXXML file may
> differ from what a syndication pipeline might do. In each case the
> processing may also vary according to the context in which the data is
> encountered. A mimetype-style grouping of purposes might be one
> approach, but I suppose the easiest would be keep such information at
> the client end, so once given the purpose it can figure out what to do
> for itself.
Cool. Reminds me a little of a Cocoon pipeline.
One thing to note is that RDDL is centralized; the descriptor is
stored at the namespace URI. It's designed to point to schemas
and other things that go along with making a namespace, so
having it controlled by the namespace owner is fine in this
context. In the application domain though, third parties should
be able to write a handler for a type of data without having to
work with the namespace owner to add it to their RDDL file.
Before finding RDDL, I was working on something named typekit,
which is a lot like RDDL, just a directory of resources with a
descriptor. The idea was that these resource directories could
be deployed on any host and then would be merged together into a
cached map of how to handle element x from namespace y in
context z. Anybody could host a typekit server and maybe they
could even communicate with each other through some kind of
inter-server communication sort of like DNS. Crazy idea?
Seems like a system like this could be really useful. The most
immediate application that comes to mind is syndication modules
like supported in RSS and Atom. When an aggregator comes across
an item that has data from say the mod_cc module, it could query
a map server and figure out where to download the appropriate
handler. In this case it might be an XSL stylesheet for an
HTML-based aggregator that would transform the <cc:license/>
into a little HTML fragment that says "Creative Commons" and
links to the license. Or maybe it could be a XUL-based
aggregator that would transform the data into some XUL
component, or a Flash aggregator that would transform the data
into a dancing and whirling creative commons icon or play a
little sound, who knows.
Another benefit is that the way things are right now, module
writers have to write a module for each flavor of syndication
feed they want to support, or maybe not, but the relationship
there isn't clear to me anyway. This way people could just
author a single piece of data for representing a creative
commons license irrespective of any context. Hardly a new
concept, pretty much the bedrock of how XML is supposed to work.
Eric
|
