Bugzilla – Full Text Bug Listing
| Summary: | Should http://www.w3.org/2001/03/xml.xsd be cached | ||
|---|---|---|---|
| Product: | [Modeling] EMF | Reporter: | Francis Upton IV <francisu> |
| Component: | XSD | Assignee: | Ed Merks <Ed.Merks> |
| Status: | NEW --- | QA Contact: | |
| Severity: | enhancement | ||
| Priority: | P3 | ||
| Version: | unspecified | ||
| Target Milestone: | --- | ||
| Hardware: | All | ||
| OS: | All | ||
| Whiteboard: | |||
|
Description
Francis Upton IV
EMF itself doesn't reference these schemas so I'm not sure we should be in the business of redirecting more URIs by default... (In reply to comment #1) > EMF itself doesn't reference these schemas so I'm not sure we should be in the > business of redirecting more URIs by default... I think as general purpose XSD support (which is what people can use the XSD stuff for -- that's what I do), it would be good to have the some of the standard schemas built in so that we don't hit the W3C site. Without doing it, it's hard for people to figure out they should preload the schema (it's not well documented), and the bandwidth cost of the remote access is high. I don't think there is a downside to redirecting these standards. It seems we'd need to remap a bunch...
http://www.w3.org/2009/01/xml.xsd
http://www.w3.org/2007/08/xml.xsd
http://www.w3.org/2004/10/xml.xsd
http://www.w3.org/2001/03/xml.xsd
Why is 2001/03 particularly special of all these?
(In reply to comment #3) > Why is 2001/03 particularly special of all these? It's not, it's just something I found in one of the standard xsds that are out there (something like the geocode.xsd). I think we should probably do all of those that you suggest. There is really no cost to it and it saves a lot of problems. (I don't understand why there are so many, but it would be good for them to be handled so long as they are really standards). Suppose though that xml.xsd at http://www.w3.org/2001/xml.xsd is changed to add something. It is defined to be always the latest version and EMF/XSD tries to keep a cache of that latest version. But all those older versions are defined to be never changing, so redirecting those URIs to the latest version isn't quite right, don't you think? (In reply to comment #5) > Suppose though that xml.xsd at http://www.w3.org/2001/xml.xsd is changed to add > something. It is defined to be always the latest version and EMF/XSD tries to > keep a cache of that latest version. But all those older versions are defined > to be never changing, so redirecting those URIs to the latest version isn't > quite right, don't you think? Below I think is the excerpt from xml.xsd that explains it pretty thoroughly (you probably already looked at this). So the current cache mechanism is a bit flawed because you are going to the whatever xml.xsd file was current at the time of the MDT/XSD software release. I think each version below should be cached with the corresponding version of xml.xsd, and new ones should be added as they come out, and also the documentation should state that the xml.xsd is cached (as mentioned above) so that people expecting the current version of xml.xsd at execution time won't be disappointed (it should also document a way to override the caching so that if you wanted the current one, you could do it yourself). If you want I can help come up with the text for the documentation, if you point me to a link of where it should be added. ---- Versioning policy for this schema document In keeping with the XML Schema WG's standard versioning policy, this schema document will persist at http://www.w3.org/2009/01/xml.xsd. At the date of issue it can also be found at http://www.w3.org/2001/xml.xsd. The schema document at that URI may however change in the future, in order to remain compatible with the latest version of XML Schema itself, or with the XML namespace itself. In other words, if the XML Schema or XML namespaces change, the version of this document at http://www.w3.org/2001/xml.xsd will change accordingly; the version at http://www.w3.org/2009/01/xml.xsd will not change. Previous dated (and unchanging) versions of this schema document are at: http://www.w3.org/2009/01/xml.xsd http://www.w3.org/2007/08/xml.xsd http://www.w3.org/2004/10/xml.xsd http://www.w3.org/2001/03/xml.xsd I don't know if I really I want to be in the business of caching a growing stack of xml.xsds. We certainly need a cached one to deal with our cached version of XMLSchema.xsd (so that XSD can initialize itself without access to the internet) but beyond that, I'm not sure anyone should be expecting there to be cached versions of anything else... Sure xml.xsd could change in the future, but that's a problem we can't solve by caching more things... (In reply to comment #7) > I don't know if I really I want to be in the business of caching a growing > stack of xml.xsds. We certainly need a cached one to deal with our cached > version of XMLSchema.xsd (so that XSD can initialize itself without access to > the internet) but beyond that, I'm not sure anyone should be expecting there to > be cached versions of anything else... > > Sure xml.xsd could change in the future, but that's a problem we can't solve by > caching more things... Fair enough, but I think it would be very useful if this were documented somewhere on the MDT/XSD site so that people could easily handle it by themselves and not have to figure it out. What specifically do you want people to be able to handle themselves? Caching of schemas? I think WTP does provide support for that already doesn't it? I.e., they have a way to specifying the locations of schemas so you could specify something that's local to your machine right in the IDE... (In reply to comment #9) > What specifically do you want people to be able to handle themselves? Caching > of schemas? I think WTP does provide support for that already doesn't it? > I.e., they have a way to specifying the locations of schemas so you could > specify something that's local to your machine right in the IDE... I don't use WTP. I use the XSD stuff in isolation without anything higher level (no EMF either). And in my application I need to cache everything that's standard so that internet access is not required (right now it goes to the net to read the xml.xsds that have the year and month in them. Maybe I'm an outlier, but I think this is an important requirement for the standalone use of XSD. There is general EMF support for URI mappings, via the resource set's URI converters URI map, and also including an extension point, uri_mapping, for registering them globally. These aren't XSD specific and work for all resources. I think that's all you're asking for... Actually I have what I need, I filed this for the next guy so they will not have to go through what I went though. I think maybe something can be put in the FAQ about this and can just refer to this bug report. |