Re: Use cases [was: How could RDDL be distributed ?]

[Jonathan Borden <jborden@mediaone.net>]

Eric van der Vlist wrote:

>
> I can see 4 of them.
>
> 1) Network optimization and reliability.
>
> Need to avoid that the servers for the most commonly used namespaces
> become hot spots and we need to make sure we can still process documents
> if/when one of them stops working.
>
> Possible solutions:
>   - URI resolution servers
>   - xmlcat
>   - Mirror and replication information within RDDL.

I think that, as has already been stated, much of this problem is not unique
to RDDL but a property of the web infrastructure and URL resolution in
general. Certainly HTML solves this 'problem' by generally ignoring the
<!DOCTYPE> decl the lesson being that software needs to consider when and
how often it really does need to dereference schemata.

Caching and load balancing solutions have already been proven to help,
though do have their own issues. I suppose this all depends on how often we
expect RDDL documents to change.

Can RDDL help here? Possibly, and we ought look at how link 'purposes' i.e.
arcroles might be able to encode mirror and replication information. We then
need client and server software that understands such information. I can
imagine an Apache module, or a RESCAP server that might suck in a RDDL
document and use it for various purposes. These purposes are orthogonal to
the RDDL spec itself, which I think with a 'role', 'arcrole', 'href', 'id',
and 'title' can support such uses. What we really need now is some
implementation experience to guide the development of these 'purposes'.

>
> 2) Occasionaly connected users.
>
> Need to be able to process documents when we are off line.
>
> Possible solutions:
>   - URI resolution servers with controlable cache
>   - local xmlcat
>   - Run time (API) definition of alternate locations
>     (could rely on xmlcat...)

Right. I think this is where an implementation of xmlcat might help. The
Java API so far supports the SAX EntityResolver hook in order to obtain the
RDDL document from the namespace URI in the first place. My thinking is that
we should encourage various RDDL API implementations to support similar
EntityResolver hooks.

>
> 3) Untrusted documents.
>
This is a general problem whenever a URL is resolved, especially into
something like a schema, no? Good problem to solve :-)

>
> 4) Additional customization of vocabularies.

this and-
>
> Need to supply alternate locations for documents we are authoring to use
> a specific set of resources.

this, seem like distinct issues.
>
> Possible solutions:
>   - setup of specific URI resolution servers
>   - local xmlcat

my thinking is that local xmlcat would be an excellent way to allow a user
to override a default URL resolution process.

>   - Definition of alternate locations within instance documents.

Can't we just use xsd:schemaLocation= for this? A RDDL/XSD aware processor
(IMHO)
ought parse a RDDL document retrieved from an xsd:schemaLocation to retrieve
a schema resource. Were you thinking of something other than this?

>
> Does it look like a sensible summary ?
> Do you see other cases and/or solutions ?
>

I think that's a good list. In particular "4) Additional customization of
vocabularies." We define vocabularies as xl:role/xl:arcrole or
nature/purpose pairs. We can go far to enhance what RDDL aware software can
accomplish by defining mutually agreed upon 'vocabularies' for expressing
these use cases. We should however try to interoperate with rather than
replace existing solutions/efforts such as xmlcat, RESCAP etc. whenever
possible. That can be accomplished by software.

-Jonathan