Cart
[Home] [By Thread] [By Date] [Recent Entries]
On Tue, Jan 16, 2001 at 04:45:12PM +0100, Eric van der Vlist wrote: > 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. Yes. This is the core use case for the URI resolution stuff. > 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...) I would add a c15n type solution here. We don't have a protocol but its a fairly simple idea.... > 3) Untrusted documents. > > Need to be able to supply alternate locations without modifying a > document in order to process it with our own set of resources. > > Possible solutions: > - setup of specific URI resolution servers > - local xmlcat > - Run time (API) definition of alternate locations > (could rely on xmlcat...) Same c15n solution as #2. Essentially #2 and #3 are the same functionally. The only difference being the actual reason why you would be using some other copy instead of the authoritative one. > 4) Additional customization of vocabularies. > > Need to supply alternate locations for documents we are authoring to use > a specific set of resources. > > Possible solutions: > - setup of specific URI resolution servers > - local xmlcat > - Definition of alternate locations within instance documents. Hmmm... seems to be the same as 2 and 3 to me. I.e. you end up doing the same thing except that the reason for doing it changes... -MM -- -------------------------------------------------------------------------------- Michael Mealling | Vote Libertarian! | www.rwhois.net/michael Sr. Research Engineer | www.ga.lp.org/gwinnett | ICQ#: 14198821 Network Solutions | www.lp.org | michaelm@n...
|
