OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

 


 

   Re: RDDL -- How would you design it?

[ Lists Home | Date Index | Thread Index ]
  • To: The Deviants <xml-dev@lists.xml.org>
  • Subject: Re: RDDL -- How would you design it?
  • From: "Clark C . Evans" <cce@clarkevans.com>
  • Date: Mon, 21 Jan 2002 14:29:32 -0500
  • In-reply-to: <575CBD83AE7DD411A23500B0D049C2F941A44D@SRVSOCRATE>; from nicolas.lehuen@ubicco.com on Mon, Jan 21, 2002 at 07:02:28PM +0100
  • References: <575CBD83AE7DD411A23500B0D049C2F941A44D@SRVSOCRATE>
  • User-agent: Mutt/1.2.5i

I started a converstation with Nicholas off line, and he 
suggested we continue it on xml-dev.  

On Mon, Jan 21, 2002 at 07:02:28PM +0100, Nicolas LEHUEN wrote:
| Today, each kind of meta-data resource has its own way of binding itself to
| a document : stylesheets use <?xml-stylesheet PIs, DTDs use the DOCTYPE
| declaration, XML Schemas use attributes from a special namespace, etc. etc.
| This result in documents that are overloaded with resource linking
| directives, document types that are not easy to maintain (if I want to add a
| schema in a new language, I have to modify all documents instance since
| there is no central directory to add the resource to), and severe
| restrictions in meta-data discovery, because I have to know all potential
| meta-data types to follow the linking method, PI names or attributes names
| that they decided to implement...
| 
| A standardized way of linking a document to a document-type specific
| resource catalog would solve this problem. That's what I'd like to design
| with other people. But this needs to agree on what is a document-type, to
| begin with.
| 
|  http://nicolas.lehuen.com/Articles/Programming/XML/fog0000000033.html

Ok.  Here is a simple "model" for resources as a straw-man.

---
Document:
  This is a serialized entity.

Class:
  This is a collection of documents which are
  somehow related.  A concrete implementation
  of a class could be a namespace URI; but 
  not all namespace URIs are classes.

Resource:
  This is a Document which contains information 
  related to a Class.   Since the Resource is
  a document, it may belong to a Class. 

  Examples of Resouce Classes include, but are
  not limited to... (a) schema to validate Documents 
  beloning to the Class, (b) transforms from documents 
  in the related Class to another Class, (c) human-readable
  texts, such as an HTML document.

Authority:
  This is an undefined object which is vouches for
  the autenticity of a Resource.

Bundle:
  This is a tuple of (a) Authrority, and (b) a list 
  of zero or more Resources.

Directory:
  This is a collection of Bundles.

---

Questions for the model...

 a. Can a Document belong to more than one Class?
   
 b. Can a Bundle have Resources from more than 
    one Class?  If so, is Directory redundant?

 c. Can a Class have more than one Bundles?
  
 d. Are authorities attached to Resources or Bundles?
    Are Authrorities even necessary?  

Questions for an XML version of the model...

 1. Are Classes namespace URIs?  Are all URIs a Class?

 2. If URIs are classes, is the document's Class the 
    namespace of the root element?  Is it's collection
    of classes (if A is yes) the collection of namespaces
    within a XML document?

---

A few requirements that come to mind:

 A. It should be easy to get from a Document to
    the resource Bundle(s) associated with
    the document.

 B. It should be flexible so that any Authority can
    associate a Resource with a Class.

 etc.


Anyway.. this is just a simple "first-pass" and I'm sure
it lacks many of the concerns necessary; but with some luck
it could be a bootstrap for a nice requirements discussion
on this topic?  RDDL is nice, but it seems that it is lacking
in more than one facet; so perhaps we could work out a model
and requirement set first and then see how RDDL does.  If
RDDL does well and can be expanded... great.  If not, then
perhaps we should look towards another solution that meets
the requirements?

Clark

-- 
Clark C. Evans                   Axista, Inc.
http://www.axista.com            800.926.5525
XCOLLA Collaborative Project Management Software




 

News | XML in Industry | Calendar | XML Registry
Marketplace | Resources | MyXML.org | Sponsors | Privacy Statement

Copyright 2001 XML.org. This site is hosted by OASIS