Cart
|
[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](/images/get_stylus.gif) 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! 
Download The World's Best XML IDE!Accelerate XML development with our award-winning XML IDE - Download a free trial today! Subscribe in XML format
|
|||||||||
