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

RDDL requirements

  • From: Jonathan Borden <jborden@m...>
  • To: xml-dev@l...
  • Date: Fri, 12 Jan 2001 23:00:47 -0500

schematron schema dtd
Jason Diamond wrote:
> ...
> But, it should obviously be permissable for multiple
> resources to have the same types.

> I'm not entirely certain that this is what RDDL is supposed to do,
> though. The beauty of it was that it was simple as well as useful.
> Would anybody care to draft a list of requirements that RDDL should
> adheed to for a first release? To be honest, the utility it's
> supposed to provide keeps drifting in and out of focus for me. If we > had
a succint set of goals, we might be able to avoid ambiguities
> like this.

The beginning of the RDDL spec says:

"This document defines Resource Directory Description Language (RDDL). A
Resource Directory provides a text description of some class of resources
and of other resources related to that class. It also contains a directory
of links to these related resources."

Assuming we wish to rereference a namespace URI, what should the document
be? SOAP wants to see an XML Schema, RDF wants to see an RDF Schema, people
who just use the web expect to see an HTML document.

RDDL provides a mechanism that satisfies all the above. We will release code
that allows an application to 'ask' for what it wants from a namespace URI.
e.g. in the most general case to dereference the RDDL document, look up the
specific resource and fetch it, thus 'dispatching' on the xlink:arcrole and
xlink:role attributes. (This can also be done on the server if efficiency is
a concern)

The point is that a namespace URI shouldn't be hardwired to a single
resource, rather each user application which uses namespaced XML documents
can dereference the namespace to find the resource it needs whether that be
an XML Schema, RDF Schema, Schematron Schema, DTD, Relax Schema ... or a
simple description of what the namespace is used for, or what elements are
contained in the namespace.
Perhaps another application wants to obtain some Python code from a
namespace URI. RDDL is designed to document the namespace URI by prose
(XHTML) as well as provide a directory of links to resources associated with
the namespace.

So, to answer the question:

One thing RDDL is designed to do is to describe a namespace in a way that
people can understand and in a way that machines can use.

Is RDDL limited to namespace URIs?

No. A namespace URI is a URI. RDDL is a way to describe a URI using prose
and as a collection of resources. The xlink:arcrole tells us about the link
to the resource and the xlink:role attribute tells us about the resource
itself.

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?

-Jonathan


PURCHASE STYLUS STUDIO ONLINE TODAY!

Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced!

Buy Stylus Studio Now

Download The World's Best XML IDE!

Accelerate XML development with our award-winning XML IDE - Download a free trial today!

Don't miss another message! Subscribe to this list today.
Email
First Name
Last Name
Company
Subscribe in XML format
RSS 2.0
Atom 0.3
 

Stylus Studio has published XML-DEV in RSS and ATOM formats, enabling users to easily subcribe to the list from their preferred news reader application.


Stylus Studio Sponsored Links are added links designed to provide related and additional information to the visitors of this website. they were not included by the author in the initial post. To view the content without the Sponsor Links please click here.

Site Map | Privacy Policy | Terms of Use | Trademarks
Free Stylus Studio XML Training:
W3C Member
Stylus Studio® and DataDirect XQuery ™are products from DataDirect Technologies, is a registered trademark of Progress Software Corporation, in the U.S. and other countries. © 2004-2013 All Rights Reserved.