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

 


Help: OASIS Mailing Lists Help | MarkMail Help

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [RDDL] Cache / Security Model



Jeff Rafter wrote:

> I have seen this group actually take on some of the more challenging,
> controversy laden, arguments lately with success, so I thought I would
start
> us on another.  Should RDDL have a layer that implements a caching
mechanism
> which contains: expiration dates, automatic lookup, namespace aliases,
> public/private key signing, options for turning off namespace resolution?

When trying to solve a difficult problem, I think it is best to subdivide
such a problem into solvable units. Hopefully RDDL solves a problem. Rather
than burden RDDL with other truly difficult problems, let's see how RDDL may
work with other solutions. At present RDDL is a document format. The issues
you raise involve protocols. In my view, software implementations as they
become increasingly sophisticated will hopefully provide solutions to the
real problems you address.

>
> My thinking is that this would address some of the biggest question marks
> left regarding RDDL.  Such as:
>
> 1) Should the namespace be resolved blindly?-- I think yes, but if your
> parser implemented an RDDLCache with an RDDLSecurityLayer you could turn
it
> off if you disagree.

    A 'RDDLCache' is a great idea for a client side implementation. Perhaps
something like BerkleyDB or another relatively lightweight client side
database can suck in RDDL documents, and perhaps this could be integrated
with a client side document cache.

>
> 2) Will usages of common namespaces (such as the XHTML or XML Schema
> namespaces) overload the Internet?-- Probably and having a caching system
> built into the resolution model would alleviate some of that.  Namespace
> aliases could also help in this area-- they could point to a local cache
or
> another trusted server where the appropriate documents are stored.

Right, or as with today's browsers that first check the local cache.

>
> I think that the signing mechanism would be a great addition and might
help
> to satisfy some of the trust issues that have been brought up. I am
thinking
> in VERY simple terms right now, however-- not some overarching Internet
> changing system that takes months to agree upon.  Only the basics with the
> mindset of developer extension.
>
> One possible extension would be an RDDLMap that would create an XML tree
of
> all included (nested) resources referred to by the RDDL-- it may even
point
> out circular references to namespaces-- just a thought.

The idea of developing a client side cache is right on (IMHO). My very
simple implementation uses trees because they are provided in JDK 1.2 (and
are available for JDK 1.1), but a lightweight client side table would solve
all the problems my implementation has and more.

-Jonathan