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

 


Help: OASIS Mailing Lists Help | MarkMail Help

 


 

   Re: [xml-dev] Re: RDDL -- How would you design it?

[ Lists Home | Date Index | Thread Index ]


----- Original Message -----
From: "Clark C . Evans" <cce@clarkevans.com>
To: "The Deviants" <xml-dev@lists.xml.org>
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
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.

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.

> 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.

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.

> Authority:
>   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 ?

> 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

Thanks for your input :).

Regards,
Nicolas

> --
> 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>
>
>






 

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

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