- From: Dan Connolly <connolly@w3.org>
- Date: Mon, 10 Jul 2000 08:51:45 -0500
- To: "Simon St.Laurent" <simonstl@simonstl.com>
- CC: xmlschema-dev@w3.org
"Simon St.Laurent" wrote: > > At 08:27 AM 7/10/00 -0500, Dan Connolly wrote: > > >We should add local catalog/caching support to XSV, ala SP's[1]. > >It shouldn't be necessary for folks to mess with their instance > >documents just to tell XSV where local copies of web resources > >are available. > > > >In fact, XSV does have a primitive form of catalog, doesn't > >it? It accepts the equivalent of schemaLocation stuff > >on the command line, no? (browse source code a bit...) > >no, I guess it doesn't. > > > >[1] "SYSTEM sysid1 sysid2 > > This specifies that sysid2 should be used as the effective system > > identifier if the system identifier specified in the external > >identifier was > > sysid1. sysid2 should always be quoted to ensure that it is not > > misinterpreted when parsed by a system that does not support this > > extension. " > > Is there any chance this kind of processing could be described in the XML > Schemas spec itself, much as XML 1.0 describes PUBLIC identifiers? Why should the schema spec specify how to dereference a URI? I'm just talking about a little caching mechanism, not anything specific to schema processing. > I think we've already got enough problems with underspecified usage of URIs > in various specifications as it is... For example? I've seen specs that are inconsistent (XML 1.0 uses 'URI' in the text, but gives examples containing relative URI references) and some that are misunderstood, but I'm not aware of any that are underspecified. > I'd like very much to see this functionality, but I'd strongly prefer that > it not be an ad hoc kind of thing. I strongly prefer that the schema spec doesn't exceed its scope and get into stuff like how to dereference URIs. But perhaps a little NOTE on how to support local copies of stuff in the Web, especially in XML software, would be useful. -- Dan Connolly, W3C http://www.w3.org/People/Connolly/
Received on Monday, 10 July 2000 10:02:35 UTC