Cart
|
[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] Re: Use cases [was: How could RDDL be distributed ?]
 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 [expletive deleted] 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 
|
PURCHASE STYLUS STUDIO ONLINE TODAY!Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced! 
Download The World's Best XML IDE!Accelerate XML development with our award-winning XML IDE - Download a free trial today! Subscribe in XML format
|
|||||||||
