[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message]

RE: Schema Namespace name, schemaLocation, and Schema V ersion


satish ramanathan
Title: RE: Schema Namespace name, schemaLocation, and Schema Versioning

Thanks, Joe 

 

That reflects our current thinking (although I'd happily discuss alternate viewpoints).

 

This seems to be a fairly clean and well-defined approach. My concern, which I hope the membership can address, would be the ramifications on application builders. Is it easier or harder to migrate both the vocabulary and the namespace names?

 

Of course, this depends on the application architecture. And if one uses some form of mapping middleware, it would also depend on the tools' handling of namespaces (which is one of the many Schema capabilities that middleware vendors are scurrying to accommodate).

 

Anybody have any insights on this?

 

Thanks,

 

Mark

 

 

 

-----Original Message-----
From: CHIUSANO, Joseph [mailto:JCHIUSANO@l...]
Sent: Tuesday, July 16, 2002 6:31 PM
To: Mark Feblowitz; 'Xml-Dev (E-mail)'
Cc: 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

 

Mark,

I too have spent time thinking about this very issue.  I would say that if your namespace is associated with an XML vocabulary, then changes in the namespace identifier could be in sync with changes in the vocabulary - that is, if a construct has two different "treatments" in two different "versions" of the vocabulary (by that I mean perhaps a later version adds additional elements to a content model), or new constructs are added to the vocabulary, then the namespace identifier could change in some way to reflect the new version of the vocabulary.  If, however, there are X schemas that are all based on the same version of a vocabulary, then I would say the namespace identifier should remain the same, but the version information could be reflected in the schema filename.

Hope that helps,
Joe Chiusano
LMI

> **************************************************************************
>   Joseph M. Chiusano
>   Logistics Management Institute
>   2000 Corporate Ridge
>   McLean, VA 22102
>   Email: jchiusano@l...
>   Tel: 571.633.7722
> **************************************************************************
>

 

-----Original Message-----
From: Mark Feblowitz [mailto:mfeblowitz@f...]
Sent: Tuesday, July 16, 2002 5:04 PM
To: 'Xml-Dev (E-mail)'
Cc: Duane Krahn (E-mail); Satish Ramanathan (E-mail); Andrew Warren
(E-mail); Kurt A Kanaskie (Kurt) (E-mail); Mark Feblowitz; Michael
Rowell (E-mail)
Subject: Schema Namespace name, schemaLocation, and Schema
Versioning

 

I've read the Best Practice, debated the pros and cons, and am still not
confident that I understand all of the ramifications: How should I associate
evolving schema version numbers into my namespace name? Into my
schemaLocation?

I have a set of schemas, all under the same namespace name, that will
certainly change over time.

Some changes will be major, some minor, some "trivial" (with numbering
reflecting the various levels, e.g., 2.3.1).

I know that if I want validators to validate the content, without writing
custom code that inspects the xml doc's content, the doc's schemaLocation
must reflect the specific version information (e.g.,
http://www.MyStandard.org/2.3.1/xyz.xsd).

I know that each schema change could affect the content in the instance
documents (changing the wire signature), and/or the names and/or structure
of the schema, which could adversely affect those schemas that import or
include the altered schema.

As such, each change reflects a different version of the schema (and thus a
new schemaLocation, e.g., http://www.MyStandard.org/2.3.1/xyz.xsd).

But does each change warrant a new namespace name?

How much of a change to the schema truly warrants a change to the namespace
name? (Some say: "any change." Some say: "only non-backward-compatible
changes," whatever those might be).

What are the ramifications of fine-grained versioning in the schema
namespace (e.g., http://www.MyStandard.org/2.3.1/xyz.xsd)?

What are the ramifications of course-grained versioning in the schema
namespace (e.g., http://www.MyStandard.org/2.3/xyz.xsd)?

With well-componentized schemas, I understand that every change to the
schema would require a change to the namespace declaration in every included
schema, in order for namespace names to match. With a good configuration
management system, this can be supported trivially. For those who don't use
these tools, this can be tedious and error prone.

I can tell you at the moment, I'm leaning toward having three levels of
version numbering, and only reflecting major and minor version numbers into
the namespace name. But as I said, I'm not confident about the distinction
between "minor" and "trivial," nor am I convinced that there would be no
adverse impacts on the schemas' deployability/usability.

From a pure xml standpoint, my current approach will work, although I'm
still unsure whether any change, no matter how trivial, would represent both
an identical vocabulary (in the instances) and an identical meta-vocabulary
(in/among the schemas).

But from a practical, production perspective, I am unsure how the
schema-consuming middleware would accommodate the changing namespace names.
Certainly, new maps would have to be created for each element/attribute in
each new namespace name. Not so for most of the content, if the namespace
name was held stable and the predominant changes were extensions.

So what's your take ?( I know this is more of a philosophical rather than
pure technical question). When should a namespace name change to reflect
changes in the schemas? What granularity do you recommend? What practices
are so common that I should just accept them, even if they don't fully
answer my (many) questions?

Where can I look, beyond the xfront site, to get insight into common
practice, ramifications, etc.? Is this question better asked under the
XML-Dev list?

Thanks,

Mark

Mark Feblowitz                                         
XML Architect
       [t]   617.715.7231                                      
       [f]   617.495.0188
Frictionless Commerce Incorporated     
       [e]  mfeblowitz@f... <mailto:mfeblowitz@f...>

       [w] http://www.frictionless.com <http://www.frictionless.com>
       [m] 400 Technology Square, 9th Floor
             Cambridge, MA 02139
Open Applications Group Incorporated
       [e]  mfeblowitz@o...
<mailto:mfeblowitz@o...>
       [w] http://www.openapplications.org <http://www.openapplications.org>

 

-----------------------------------------------------------------
The xml-dev list is sponsored by XML.org <http://www.xml.org>, an
initiative of OASIS <http://www.oasis-open.org>

The list archives are at http://lists.xml.org/archives/xml-dev/

To subscribe or unsubscribe from this list use the subscription
manager: <http://lists.xml.org/ob/adm.pl>


PURCHASE STYLUS STUDIO ONLINE TODAY!

Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced!

Buy Stylus Studio Now

Download The World's Best XML IDE!

Accelerate XML development with our award-winning XML IDE - Download a free trial today!

Don't miss another message! Subscribe to this list today.
Email
First Name
Last Name
Company
Subscribe in XML format
RSS 2.0
Atom 0.3
 

Stylus Studio has published XML-DEV in RSS and ATOM formats, enabling users to easily subcribe to the list from their preferred news reader application.


Stylus Studio Sponsored Links are added links designed to provide related and additional information to the visitors of this website. they were not included by the author in the initial post. To view the content without the Sponsor Links please click here.

Site Map | Privacy Policy | Terms of Use | Trademarks
Free Stylus Studio XML Training:
W3C Member
Stylus Studio® and DataDirect XQuery ™are products from DataDirect Technologies, is a registered trademark of Progress Software Corporation, in the U.S. and other countries. © 2004-2013 All Rights Reserved.