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

Re: Re: [namespaceDocument-8] 14 Theses


Re:  Re: [namespaceDocument-8] 14 Theses
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

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.