[
Lists Home |
Date Index |
Thread Index
]
Tim Bray wrote:
> Right... Ron and Rick, could your needs with respect to context
> and phase be met by combination of natures/purposes?
It's theoretically possible, but unrealistic in practice. The problem is
that requiring a namespace to know about the contexts in which it is
used is inside out -- rather like requiring me to document the links
that other people make to my Web site.
> Failing this, what kind of machinery would you need to meet
> your needs? -Tim
Actually, the RDDL machinery is not bad. The problem for me is that it
is associated with a namespace, rather than the document as a whole (or
even an application/document combination).
Of course, the real problem is what is realistic. If you associate a
RDDL document with a particular document "type", then you still have an
inside-out problem -- the document can't possibly provide information
about all the applications that can use it.
On the other hand, if you associate the document with a particular
combination of application and documentation, you've probably made the
contents of the document so application-specific that it's only of
interest to that application, and therefore loses its general interest.
(You've also moved closer to Simon's XML Processing Description
Language. Inherent in XPDL is the notion that there can be many XPDL
documents associated with a given XML document. This contradicts the
basic idea of a RDDL document, which is to provide general information.)
So it seems there are three rough levels:
1) Provide information at the namespace level. RDDL does this today. The
namespace <=> RDDL association is a big advantage, as it means people
can find the information. The disadvantage is that the information lacks
context.
2) Provide information at the document (vocabulary) level. This is
better, but (a) there is no current mechanism for finding the
information, and (b) a lot of information will probably be repeated with
slight variations when elements from a given namespace are used in
different documents.
3) Provide information at the application/document level. The
information is close to complete, but probably too specific. Again, no
current mechanism exists.
The more I think about this, (1) and (2) are both good things, but are
primarily for human audiences; the controversy arises because of
expectations surrounding the machine audiences. The only machine
audience for either is likely to be a development environment. If this
is what was intended, then the problem is one of overselling the
capabilities of RDDL, rather than RDDL itself.
((3) is also good, but unrelated, as it is solving a processing problem
rather than a resource list problem.)
-- Ron
|
