Lists Home |
Date Index |
----- Original Message -----
From: "Clark C . Evans" <firstname.lastname@example.org>
To: "The Deviants" <email@example.com>
Sent: Monday, January 21, 2002 8:29 PM
Subject: [xml-dev] Re: RDDL -- How would you design it?
> 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
> | a document : stylesheets use <?xml-stylesheet PIs, DTDs use the DOCTYPE
> | declaration, XML Schemas use attributes from a special namespace, etc.
> | This result in documents that are overloaded with resource linking
> | directives, document types that are not easy to maintain (if I want to
> | 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
> | meta-data types to follow the linking method, PI names or attributes
> | 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
> | with other people. But this needs to agree on what is a document-type,
> | begin with.
> | http://nicolas.lehuen.com/Articles/Programming/XML/fog0000000033.html
> Ok. Here is a simple "model" for resources as a straw-man.
> This is a serialized entity.
> 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.
Wow. I was shyly trying to write about types and Simon was already upset,
but you go directly for 'class' :). No pb with your definition, otherwise.
> 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.
I would use a more specific term like meta-data resources or any better term
you can find. Resource is already used to describe something that a URI can
be resolved into. But once again, no problem for your definition.
> This is an undefined object which is vouches for
> the autenticity of a Resource.
I didn't thought of that : ensuring the authenticity of meta-data. That's a
good idea, but why extend it to the more general problem of ensuring the
authenticity of any resource (XML document, meta-data, binary files, etc.)
and let someone else work on it ?
> This is a tuple of (a) Authrority, and (b) a list
> of zero or more Resources.
> 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.
> 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?
Thanks for your input :).
> Clark C. Evans Axista, Inc.
> http://www.axista.com 800.926.5525
> XCOLLA Collaborative Project Management Software
> The xml-dev list is sponsored by XML.org <http://www.xml.org>, an
> initiative of OASIS <http://www.oasis-open.org>
> The list archives are at http://lists.xml.org/archives/xml-dev/
> To subscribe or unsubscribe from this list use the subscription
> manager: <http://lists.xml.org/ob/adm.pl>