Cart
|
[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] RE: Schema Namespace name, schemaLocation, and Schema V ersio
 Jeni - As usual, very eloquently stated, very thought-provoking, and very helpful. And you have called our attention to a useful distinction: between the markup version and the schema version. Each of these is has an objective, concrete definition, and gets us away from the subjective criteria around "major" versus "minor" versus "trivial" changes. I also appreciate your comments on the impacts of markup changes on XSL (and, for that matter, any application). That is a potentially serious concern when altering the markup - that all XPath expressions would have to be reviewed and updated. In a very general, very extensible substrate vocabulary, changes to the markup are few and far between, and breakage would be rare (XSL for manipulating/formatting .xsd files would be very stable for a very long time ;-). For the rest of us, markup changes are harder to avoid. We try to reduce the likelihood of labor-intensive breakage by minimizing wholesale restructuring and keeping primarily to additions/extensions. At least in these cases, we can leave much of the XPath untouched. Given that most of our version releases would contain both schema and markup changes, it would seem that this distinction may not be that useful. And it still doesn't help me understand the ramifications of putting version information in the namespace name. This all gives me brain cramps. It's not easy to understand all of the dimensions of change, and the role of the schema, the application, and version publication policies in managing that change. Toss in the ripple effects on the applications, and you've got one rich conundrum. In our case, the "proper version" approach that you suggest would likely cause breakage for our users. Any time a new version was promoted to the proper version, anyone who didn't know about and prepare for the change would experience breakage. To recover (without doing a full upgrade), they'd have to point at an older version *and* they have to alter their namespace references, to reflect that they're using an older version. An incentive to keep up to date, but one that would require working applications to be updated (not very popular in industry). The crux of the matter is managing change: change to the markup, change to the schema(s), change to the applications that generate and process the markup, change to the stylesheets that transform/format the markup, and change to the middleware that maps the markup into other dialects and/or into databases. There is also the impact of schema change on those who build on other schema(s). If a type in one schema is renamed, that would adversely effect all who import/include the schema and reference that type. And, because this is an interchange activity, changes often ripple between enterprises. And the "art" here is in assessing what part the validating parsers play in accepting/rejecting version differences. Remove version information from the namespace name and the validator plays no direct role, at least when namespace names are compared. Add the version information and the validator plays a very direct role, rejecting mismatches and requiring interchangers to a priori agree on version. I'm still not much closer to knowing what our approach will be. I'd be happy to hear other viewpoints. Mark -----Original Message----- From: Jeni Tennison [mailto:jeni@j...] Sent: Wednesday, July 17, 2002 6:07 AM To: Mark Feblowitz Cc: 'CHIUSANO, Joseph'; 'Xml-Dev (E-mail)'; Duane Krahn (E-mail); Satish Ramanathan (E-mail); Andrew Warren (E-mail); Kurt A Kanaskie (Kurt) (E-mail); Michael Rowell (E-mail) Subject: Re: Schema Namespace name, schemaLocation, and Schema V ersioning Hi Mark, First, I think it's important to make the distinction between versions of a markup language and versions of a schema. One version of one markup language might have multiple associated versions of schemas, perhaps fulfilling different purposes, or simply developed over time. The location of the single predominant schema for a particular version of the markup language at any one time should probably be fixed, such that, for example: http://www.MyStandard.org/2.3.1/xyz.xsd always points to the XML Schema for version 2.3.1 of the markup language XYZ. [Note that the value of the 'version' attribute on the xs:schema element in XML Schema doesn't get passed through into the PSVI, so should be used to indicate the version of the schema rather than the version of the markup language. The schemaVersion attribute on sch:schema in Schematron has a similar role, I believe.] Then the question is whether you want to change the namespace with each version of the markup language. I think that this comes down to how you want processors of earlier versions of the markup language to treat documents in the new version of the markup language. If you want the applications to reject documents in the new version of the markup language completely, then you should use a different namespace for them. If you want the applications to attempt to process the documents in the new version of the markup language, then you should use a different mechanism (such as a required and fixed 'version' attribute on the document element) to indicate the version of the markup language. Also, if you want individual applications to be able to deal with more than one version of the markup language, it's helpful to use the same namespace throughout versions. Most of my reasoning behind this comes from thinking about how XSLT stylesheets would handle new versions of a markup language. XSLT (and any namespace-aware processor) treats elements in different namespaces completely differently. If you give an XSLT stylesheet designed for one namespace exactly the same document but with a slightly different namespace, it won't be able to process it properly (it won't consider it to be the "same document" at all). Changing a stylesheet to handle a new version of the markup language (with a new namespace) *instead* of the old version would be fairly easy (just change the namespace declaration and alter the templates to handle any new or altered elements), but changing it to handle a new version of the markup language (with a new namespace) *as well* would involve adding a new namespace declaration and probably changing every single path and pattern within the stylesheet. Of course if the applications that deal with a markup language don't use the namespace in any fundamental way -- if they just check it once and then using the local names of the elements in the rest of the processing -- then it's perfectly fine to use the namespace as the way of indicating the version of the markup language used in a document. Also, if there's only ever one version of the markup language in use at any one time (which I think is unlikely), changing the namespace alongside the version of the markup language would be appropriate. In general, though, I'd say that you should have a single, fixed namespace for the markup language, unchanged through the versions of the markup language. To indicate versions, you should instead have a fixed and required 'version' attribute on the document element (and perhaps elsewhere). If you adopt this scheme, it's important to have rules about what applications should do when they encounter a (new or old) version that they don't support. I think it's also useful to have one or more different namespaces for "trial" or "draft" versions of the markup language -- during initial development, for example -- so that applications that are designed to work on draft versions of the markup language reject documents in the "proper" version (and you can tell that you need to update your application) and so that documents that use the draft version of the markup language are rejected by applications that are designed to work with the proper version. So I'd have a namespace scheme like: http://www.MyStandard.org/XYZ (proper version) http://www.MyStandard.org/XYZ/0.1.0 (draft 0.1.0) http://www.MyStandard.org/XYZ/1.0.0 (draft 1.0.0) http://www.MyStandard.org/XYZ/2.3.1 (draft 2.3.1) and have schemas at locations mirroring these namespaces: http://www.MyStandard.org/xyz.xsd http://www.MyStandard.org/XYZ/0.1.0/xyz.xsd http://www.MyStandard.org/XYZ/1.0.0/xyz.xsd http://www.MyStandard.org/XYZ/2.3.1/xyz.xsd (If 2.3.1 was the current version, then http://www.MyStandard.org/xyz.xsd would be the same as http://www.MyStandard.org/XYZ/2.3.1/xyz.xsd, but with a different target namespace.) I'd anticipate having different versions of schemas for each different version of the markup language, so you might have: http://www.MyStandard.org/XYZ/2.3.1/xyz.1.xsd http://www.MyStandard.org/XYZ/2.3.1/xyz.2.xsd http://www.MyStandard.org/XYZ/2.3.1/xyz.5.xsd where the latest version of the schema for version 2.3.1 of the markup language was version 5, and thus http://www.MyStandard.org/XYZ/2.3.1/xyz.5.xsd was the same as http://www.MyStandard.org/XYZ/2.3.1/xyz.xsd. Cheers, Jeni --- Jeni Tennison http://www.jenitennison.com/ 
|
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
|
|||||||||
