[
Lists Home |
Date Index |
Thread Index
]
Thomas B. Passin (tpassin@comcast.net) wrote:
> Where I am having a problem in this thread is in understanding what
> people are asking for in the first place. Is it browser plugins? That
> works for java applets (usually), and sometimes for browser plugins
> (sometimes not, as for the Adobe svg plugin which works for IE but not
> Mozilla).
It's a plugin system analogous to a browser plugin system but
instead of mapping mime types to code, it maps data types to
uses of that data, most notable user interfaces. These user
interfaces don't actually "do" anything, they're just a face.
Or maybe there could actually be code there as well. I haven't
thought about that much. Security is an obvious issue.
You know how a schema can be referenced from inside an instance
document? And a stylesheet can be as well? These are simple
ways to make it so that when for example a browser comes across
this instance it can do something intelligent with it. Validate
it or mark it up with the associated stylesheet to HTML.
This approach is fine if you're just authoring documents to be
displayed to a browser, the document world, but IMO is totally
inadequate for the data-centric XML world. The data itself
shouldn't be tied to /any/ sort of mechanism for displaying
itself, nor should it be self-aware of how it might be used.
Because by doing so you pigeon hole the data into use in a
single context or application.
So this is a way to use just namespace/element as a primary key
to a database of contexts in which this data could be used, and
leave the data unmolested by the details of application. It's
just data.
Here's a use case:
How about a "structured" p2p application where all resources in
the network were represented by XML metadata. It's easy to see
how this would work, there would simply be two layers of
information, one of resources and one of metadata. Users would
search the metadata to locate the files they were looking for
and then download the resource.
And this application already exists. Kazaa for example keeps a
set of metadata about each file. When you share a mp3 file it
pulls data out of the id3 tag and puts it in it's "Song" schema
and when you do a search, you can search by filename or by
metadata.
But Kazaa controls the categories. It's defined a set of
buckets that each resource has to fall into. Audio, Video,
Application, Document, etc. They hardwire a user interface to
each of these categories into the app so that a regular user can
edit and view the data.
The problem with this approach is that they have to know in
advance when they deploy their app how resources are going to be
organized. It centralizes the way that resources can be
categorized and puts it in the control of the application
designer. IMO this severely limits the power of the app -- not
for how resources can be transfered, but for how they can be
organized.
The dream of an "openly structured" p2p application would be
that anybody could create a category for information, a schema,
an ontology for a specific domain of knowledge. You could
invent a schema for representing very specific types of
information like say recordings of bird calls.
What does a XML doc representing a recording of a bird call look
like?
<birdcall>
<species>Magpie</species>
<gender>male</gender>
<length>2:25</length>
</birdcall>
Maybe add other things like date and location, who knows.
So in this case, the app would work just the same. Metadata
represents resources. The problem is though, how do you
generalize it? If someone wanted to add their own category for
information, what would they need to add?
* A schema
That takes care of the data model. But then how do users add
and edit and view this data without having to edit raw XML?
This is where the plugin comes in. Along with adding a schema
to the app, a category maker could author what I've been calling
a "typekit" which is just a directory of resources for
displaying and editing data of this type in a particular
environment. Each resource would have a nature and a purpose.
In this case we might need five purposes:
* display
* simple-display
* add
* edit
* search
The nature of the two displays would be XSL transformations, and
the three forms would be XForms. So you author these five
pieces and place them in the RDDL file for your birdcall
namespace and there you have it. When anyone comes across this
instance, they can know how to display it or do a simple display
of it. Further, if they wanted to and how this relates to the
web-browser world I'm not quite sure, but they could edit the
document with the XForm associated with it.
Make sense?
I'm obviously coming to this from the typified data/ontology
world, but I think it could be applicable to a more RDF centric
approach as well, though I'm no expert on RDF.
Regards,
Eric
|
