[
Lists Home |
Date Index |
Thread Index
]
Eric Hanson wrote:
> Jonathan Borden (jonathan@openhealth.org) wrote:
>>>
>> Since you are already implementing this, you have already worked out
>> the rules by which who gets to say what about the namespace.
>
> Anyone can say anything about a namespace. The rule that isn't
> worked out is who will listen to them and how they will listen.
:-)
> It's a complex problem that tries to take into account all the
> ways an instance can be used! Such is the nature of
> generalization...less than trivial, and I sure don't have it
> figured out.
RDDL provides *a* solution to this problem, namely that you resolve the
namespace URI, get back a representation (document) and this tells you
something about the namespace.
An RDF triple store might provide, assuming some things were worked
out, a different mechanism for finding out about a namespace URI e.g. a
triple store might contain various triples that reference the URI.
>
>> RDDL would just be a replacement for your "plain vanilla XML"
>> and wherever you have an XML document you could replace that
>> with a RDDL document. RDDL is just a simple extension of XHTML
>> -- that is you create documentation of the namespace readable
>> by humans using HTML and readable by your program using the
>> RDDL extension vocabulary.
>
> The data in the two formats is pretty similar. Typekit uses
> nature and purpose as well. It adds one more property,
> mime-type, which indicates in the case of a transformation, what
> the target mime-type of that transformation is. This property
> is optional however.
If you read through the xml-dev archives, we had very early on
considered including a mime-type property -- actually this was my
initial suggestion, but then we decided this was redundant -- the
nature can serve as a URI encoding of a mime-type as is described in
the RDDL document.
>
> I'd like to find some kind of harmony between RDDL and typekit,
> so let me lay my cards on the table and say what I do and don't
> like about RDDL.
>
> Pros:
> * functionally, RDDL does a lot of the same things typekit does,
> and it's developed here.
> * nature/purpose is I think brilliant starting place for
> generalizing the description of a resource.
> * the name RDDL is a descriptive name for what I've been calling
> a typekit descriptor.
>
> Cons:
> * RDDL is an extension of XHTML, which joins data and
> presentation in a way that IMHO would be better accomplished by
> browser support for intelligently displaying XML. Granted, this
> support doesn't exist currently, but I think it could using
> something like this project.
A key, perhaps *the* only unique characteristic of RDDL is that it is
intended to be human readable. If you drop the requirement for human
readability RDDL is an utter waste of time, and you'd be far better of
using RDF directly. Since the only XML browsers I know that are
widespread use XHTML to display stuff to people, that's what we use. Of
course RDDL is also designed to be read by machines which is why it is
not simply XHTML.
Jonathan
|
