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

RE: RDDL requirements

• From: Jason Diamond <jason@i...>
• To: Jonathan Borden <jborden@m...>, xml-dev@l...
• Date: Fri, 12 Jan 2001 21:09:51 -0800

Hi.

[snip]

Thanks for the wonderful summary. Can we include something like that as an
introduction to the spec?

> Some requirements:
>
> 1) RDDL should be easy to understand
> 2) RDDL should be easy to implement
> 3) RDDL should be able to describe a namespace URI in a way that covers
> common uses of namespace URIs by people and machines.
>
> Other suggestions, ideas?

That's a great start but we need some more concrete requirements to work
with. When I asked about requirements, I was specifically referring to the
question of whether RDDL was supposed to allow multiple resources of the
same nature to be associated with a single URI. Thanks to our discussions
since then, I can see that this is desired--so it should be a requirement.

Here's my suggestions:

1) RDDL shall allow multiple (XML and non-XML) resources to be associated
with a single URI.
2) RDDL shall provide a means to specify the nature of each associated
resource.
3) RDDL shall make every attempt to use existing schemes to identify these
natures (i.e., namespaces and MIME types).
4) RDDL shall provide a means to specify the purpose of each associated
resource.
5) RDDL shall provide a directory of URIs to be used to identify these
purposes.
6) RDDL shall provide a means to specify the language of each associated
resource.

I think we've got those covered.

7) RDDL shall allow for interoperability with legacy applications that
already expect certain types of resources when dereferencing URIs.

This one's important. We need to make sure it happens.

8) RDDL shall use XHTML to provide human-readable content.
9) RDDL shall use XLink to provide machine-processable content.

Check.

Here's some requirements that we'd want to keep in mind for implementors:

10) RDDL shall provide a means to unambiguously retrieve resources using any
combination of nature, purpose, and/or language.
11) RDDL shall not impose any particular processing model upon
implementations (i.e., it should be possible to implement RDDL processors
using SAX (push), Microsoft's XmlReader (pull), and the W3C's DOM/JDOM
(tree)).

12) The RDDL spec shall be a RDDL document.
13) The RDDL spec shall clearly identify the RDDL-specific information items
that conformant processors are expected to provide.
14) The RDDL spec shall reference an XSLT stylesheet that "extracts"
RDDL-specific information items from conformant RDDL documents.
15) RDDL shall not be "released" until at least three (one for each of the
push, pull, and tree models) Open Source processors have demonstrated 100%
conformance to the spec.

These are dogfood requirements. If they can't be done, then RDDL is
worthless. We need to prove to the world (not just ourselves) that RDDL is
useful.

16) RDDL shall be free (to use and implement) for everyone.

This one's the most important of all. :-)

I'm sure I missed some but I think that this is the bulk of them. It's
incredibly slim compared to most requirements documents. And we're almost
there!

Comments?

Jason.

• References:
  • RDDL requirements
    • From: Jonathan Borden <jborden@m...>

• Prev by Date: role, arcrole, purpose, nature
• Next by Date: Place under sun (was: XPointer and Sun patent)
• Previous by thread: RDDL requirements
• Next by thread: Cobol Copybooks to XML
• Index(es):
  • Date
  • Thread