Best Practices for Establishing Namespace Name
|
View:
New views
20 Messages
—
Rating Filter:
Alert me
|
| < Prev | 1 - 2 | Next > |
 |
Best Practices for Establishing Namespace Name
by Tsao, Scott
::
Rate this Message:
We are trying to
decide on a namespace URI for an XML schema under development by a
standards committee in the aerospace industry.
Are there best
practices that we could follow? For example, the choice between URL and
URN, case sensitivity, unique components in the name, and incorporation of RDDL,
etc.
Also, are there good
example namespace names already established by standards committees such as
those in OASIS?
Thanks,
Scott
Tsao 曹壽國 |
|
|
|
|
|
Re: Best Practices for Establishing Namespace Name
by Henry S. Thompson
::
Rate this Message:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1 G. Ken Holman writes: > I regret that the OASIS policy at the release of UBL was URN-based and > not URL-based, but such was the case at the time. Just to endorse the implication here: use http: URIs, and put _something_ at that URI, even if it's only one line to tell people where to look for the details. ht - -- Henry S. Thompson, School of Informatics, University of Edinburgh Half-time member of W3C Team 10 Crichton Street, Edinburgh EH8 9AB, SCOTLAND -- (44) 131 650-4440 Fax: (44) 131 651-1426, e-mail: ht@... URL: http://www.ltg.ed.ac.uk/~ht/ [mail really from me _always_ has this .sig -- mail without it is forged spam] -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.6 (GNU/Linux) iD8DBQFKm6QvkjnJixAXWBoRAgyqAJ9pfM1JDQ/j22IKkku52hXBfn/ywgCfYr8G hB8/7uPFVTwv+vDNtfZGoxY= =3+W2 -----END PGP SIGNATURE----- |
|
|
RE: Best Practices for Establishing Namespace Name
by Tsao, Scott
::
Rate this Message:
Thanks very much for your suggestions! Is http: URI
that same as URL? And, is the use of them for
namespace names (in lieu of URN) recommended by standards
organizations such as W3C and OASIS?
The committee (we are
participating in) seems to think that we should register a formal URN namespace for "global" uses
like OASIS and S1000D have done [1], because that would allow us to use this unique
namespace as part of our schema namespace structure for different schemas in
different specifications.
[1] http://www.iana.org/assignments/urn-namespaces/ Regards,
Scott
Tsao 曹壽國
|
|
|
Re: Best Practices for Establishing Namespace Name
by Henry S. Thompson
::
Rate this Message:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1 Tsao, Scott writes: > Thanks very much for your suggestions! > > Is http: URI that same as URL? Many people use 'URL' to mean 'URI using the http: scheme', yes. > And, is the use of them for namespace names (in lieu of URN) > recommended by standards organizations such as W3C and OASIS? Absolutely. OASIS have backed off using URNs as namespace names, and W3C TAG strongly recommends using http: URIs for this purpose. > The committee (we are participating in) seems to think that we > should register a formal URN namespace for "global" uses like OASIS > and S1000D have done [1], because that would allow us to use this > unique namespace as part of our schema namespace structure for > different schemas in different specifications. Why doesn't the same apply for e.g. http://[your committee]/namespaces/xxx? Which has the additional benefit that as I mentioned before, you can document your namespace at that URI... ht - -- Henry S. Thompson, School of Informatics, University of Edinburgh Half-time member of W3C Team 10 Crichton Street, Edinburgh EH8 9AB, SCOTLAND -- (44) 131 650-4440 Fax: (44) 131 651-1426, e-mail: ht@... URL: http://www.ltg.ed.ac.uk/~ht/ [mail really from me _always_ has this .sig -- mail without it is forged spam] -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.6 (GNU/Linux) iD8DBQFKnj1akjnJixAXWBoRAgpnAJ946RWeMWRT4NA3S1hHT0bCc63GPgCcDCJp 3NNY0Glqx4E0BJeWcEZs0z8= =zpxU -----END PGP SIGNATURE----- |
|
|
Re: Best Practices for Establishing Namespace Name
by Eliot Kimber-3
::
Rate this Message:
On 9/2/09 4:39 AM, "Henry S. Thompson" <ht@...> wrote:
> -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Tsao, Scott writes: ... >> The committee (we are participating in) seems to think that we >> should register a formal URN namespace for "global" uses like OASIS >> and S1000D have done [1], because that would allow us to use this >> unique namespace as part of our schema namespace structure for >> different schemas in different specifications. > > Why doesn't the same apply for e.g. http://[your committee]/namespaces/xxx? > > Which has the additional benefit that as I mentioned before, you can > document your namespace at that URI... I had been under the impression that the Namespace recommendation specifically prohibited namespace URIs from being resolvable to anything. But I see that in the 1.1 version it says " It is not a goal that it be directly usable for retrieval *of a schema* (if any exists)." [Emphasis mine.] Which definitely allows the use Henry suggests. I had always thought that URNs were preferable simply because they *aren't* resolvable by any generally-available infrastructure. But having a URL that has documentation at the other end of it seems reasonable. Cheers, Eliot ---- Eliot Kimber | Senior Solutions Architect | Really Strategies, Inc. email: ekimber@... <mailto:ekimber@...> office: 610.631.6770 | cell: 512.554.9368 2570 Boulevard of the Generals | Suite 213 | Audubon, PA 19403 www.reallysi.com <http://www.reallysi.com> | http://blog.reallysi.com <http://blog.reallysi.com> | www.rsuitecms.com <http://www.rsuitecms.com> |
|
|
Re: Best Practices for Establishing Namespace Name
by noah_mendelsohn
::
Rate this Message:
Hi, Scott. Further endorsing the advice that Henry and Eliot have given
you, I suggest you might be interested in the TAG's finding that specifically encourages you to provide useful information that can be retrieved using the namespace URI. See [1]. Noah [1] http://www.w3.org/2001/tag/doc/nsDocuments/ -------------------------------------- Noah Mendelsohn IBM Corporation One Rogers Street Cambridge, MA 02142 1-617-693-4036 -------------------------------------- ekimber <ekimber@...> Sent by: xmlschema-dev-request@... 09/02/2009 09:12 AM To: "Henry S. Thompson" <ht@...>, "Tsao, Scott" <scott.tsao@...> cc: "G. Ken Holman" <gkholman@...>, <xmlschema-dev@...>, (bcc: Noah Mendelsohn/Cambridge/IBM) Subject: Re: Best Practices for Establishing Namespace Name On 9/2/09 4:39 AM, "Henry S. Thompson" <ht@...> wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Tsao, Scott writes: ... >> The committee (we are participating in) seems to think that we >> should register a formal URN namespace for "global" uses like OASIS >> and S1000D have done [1], because that would allow us to use this >> unique namespace as part of our schema namespace structure for >> different schemas in different specifications. > > Why doesn't the same apply for e.g. http://[your committee]/namespaces/xxx? > > Which has the additional benefit that as I mentioned before, you can > document your namespace at that URI... I had been under the impression that the Namespace recommendation specifically prohibited namespace URIs from being resolvable to anything. But I see that in the 1.1 version it says " It is not a goal that it be directly usable for retrieval *of a schema* (if any exists)." [Emphasis mine.] Which definitely allows the use Henry suggests. I had always thought that URNs were preferable simply because they *aren't* resolvable by any generally-available infrastructure. But having a URL that has documentation at the other end of it seems reasonable. Cheers, Eliot ---- Eliot Kimber | Senior Solutions Architect | Really Strategies, Inc. email: ekimber@... <mailto:ekimber@...> office: 610.631.6770 | cell: 512.554.9368 2570 Boulevard of the Generals | Suite 213 | Audubon, PA 19403 www.reallysi.com <http://www.reallysi.com> | http://blog.reallysi.com <http://blog.reallysi.com> | www.rsuitecms.com <http://www.rsuitecms.com> |
|
|
Re: Best Practices for Establishing Namespace Name
by Andrew Welch
::
Rate this Message:
2009/9/2 <noah_mendelsohn@...>:
> Hi, Scott. Further endorsing the advice that Henry and Eliot have given > you, I suggest you might be interested in the TAG's finding that > specifically encourages you to provide useful information that can be > retrieved using the namespace URI. See [1]. > > Noah > > [1] http://www.w3.org/2001/tag/doc/nsDocuments/ ...but avoid using dates, for example: http://www.w3.org/1999/XSL/Transform http://www.w3.org/2001/XMLSchema would have been much better as: http://www.w3.org/XSLT http://www.w3.org/XMLSchema ....then you don't have to reassure newbies that they really are using modern technologies (2.0 and 1.1), despite what they may think from the namespace. I would say the main thing is to choose a namespace that wont need to change, so don't use dates, versions, "beta", codenames etc. Also the namespace is often its branding, so using product names might be great until marketing change their minds and call the product something else... if the xml is visible to the customer they may ask for the namespace to change too. So as an example, if the company is called "foo" and the product is "foobar", you would probably choose "http://foo.com/foobar", which is most likely going to be ok, but I'm beginning to think that "http://foo.com/ns" is the better choice. -- Andrew Welch http://andrewjwelch.com Kernow: http://kernowforsaxon.sf.net/ |
|
|
Re: Best Practices for Establishing Namespace Name
by C. M. Sperberg-McQueen-2
::
Rate this Message:
On 2 Sep 2009, at 03:39 , Henry S. Thompson wrote: > > Tsao, Scott writes: > >> ... > >> And, is the use of them for namespace names (in lieu of URN) >> recommended by standards organizations such as W3C and OASIS? > > Absolutely. OASIS have backed off using URNs as namespace names, and > W3C TAG strongly recommends using http: URIs for this purpose. > >> The committee (we are participating in) seems to think that we >> should register a formal URN namespace for "global" uses like OASIS >> and S1000D have done [1], because that would allow us to use this >> unique namespace as part of our schema namespace structure for >> different schemas in different specifications. > > Why doesn't the same apply for e.g. http://[your committee]/ > namespaces/xxx? > > Which has the additional benefit that as I mentioned before, you can > document your namespace at that URI... The record would not be complete without someone observing that it also has the disadvantage that if the domain name registration for [your committee] ever lapses, there is no guarantee that the new owner will refrain from assigning a new meaning to http://[your committee]/namespaces/xxx The TAG is presumably aware of this problem (having had it pointed out to them more than once), and has presumably decided that it does not matter enough to make a difference. But as long as domain names are allowed to be used more than once by different owners, no system of unique identifiers built on the domain name system actually guarantees uniqueness of identifier. In the short run, that doesn't matter. Whether it matters in the long run depends on how long you want things to work, and how dependent you want to be on netscape.com, for example, continuing to denote what it once denoted. -- **************************************************************** * C. M. Sperberg-McQueen, Black Mesa Technologies LLC * http://www.blackmesatech.com * http://cmsmcq.com/mib * http://balisage.net **************************************************************** |
|
|
RE: Best Practices for Establishing Namespace Name
by Simon Cox
::
Rate this Message:
In some situations it is good to include dates or version numbers in
namespace names. For example, if your maintenance/governance arrangement expects new versions, and particularly if the new versions are not compatible with older versions. Geography Markup Language from OGC made the mistake of keeping the same XML namespace for several incompatible versions of GML, and this has caused confusion. (The policy has since been fixed). Of course, you can choose to give your new version a completely new name and namespace, but sometimes you want to claim continuity, or at least a common scope, with an earlier product, but not confuse processors by having incompatible declarations in the same target namesapce. There are no universal rules here - you need to be clear about your application and requirements. -------------------------------------------------------- Simon Cox European Commission, Joint Research Centre, Institute for Environment and Sustainability, Spatial Data Infrastructures Unit, TP 262 Via E. Fermi, 2749, I-21027 Ispra (VA), Italy Tel: +39 0332 78 3652 Fax: +39 0332 78 6325 mailto:simon.cox@... http://ies.jrc.ec.europa.eu/simon-cox SDI Unit: http://sdi.jrc.ec.europa.eu/ IES Institute: http://ies.jrc.ec.europa.eu/ JRC: http://www.jrc.ec.europa.eu/ -------------------------------------------------------- -----Original Message----- From: xmlschema-dev-request@... [mailto:xmlschema-dev-request@...] On Behalf Of Andrew Welch Sent: Wednesday, 2 September 2009 16:46 To: noah_mendelsohn@... Cc: Tsao, Scott; G. Ken Holman; Henry S. Thompson; xmlschema-dev@...; ekimber Subject: Re: Best Practices for Establishing Namespace Name 2009/9/2 <noah_mendelsohn@...>: > Hi, Scott. Further endorsing the advice that Henry and Eliot have > given you, I suggest you might be interested in the TAG's finding that > specifically encourages you to provide useful information that can be > retrieved using the namespace URI. See [1]. > > Noah > > [1] http://www.w3.org/2001/tag/doc/nsDocuments/ ...but avoid using dates, for example: http://www.w3.org/1999/XSL/Transform http://www.w3.org/2001/XMLSchema would have been much better as: http://www.w3.org/XSLT http://www.w3.org/XMLSchema ....then you don't have to reassure newbies that they really are using modern technologies (2.0 and 1.1), despite what they may think from the namespace. I would say the main thing is to choose a namespace that wont need to change, so don't use dates, versions, "beta", codenames etc. Also the namespace is often its branding, so using product names might be great until marketing change their minds and call the product something else... if the xml is visible to the customer they may ask for the namespace to change too. So as an example, if the company is called "foo" and the product is "foobar", you would probably choose "http://foo.com/foobar", which is most likely going to be ok, but I'm beginning to think that "http://foo.com/ns" is the better choice. -- Andrew Welch http://andrewjwelch.com Kernow: http://kernowforsaxon.sf.net/ |
|
|
Re: Best Practices for Establishing Namespace Name
by Henry S. Thompson
::
Rate this Message:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1 C. M. Sperberg-McQueen writes: > The record would not be complete without someone observing > that it also has the disadvantage that if the domain name > registration for [your committee] ever lapses, there is no > guarantee that the new owner will refrain from assigning > a new meaning to http://[your committee]/namespaces/xxx For sure. But be careful using this as an argument in favour of using URNs or some other URI scheme -- If you don't care about dereferencing, it doesn't matter that http://[your committee]/namespaces/xxx doesn't dereference today, and might dereference misleadingly in some relatively unlikely future. If you _do_ care, then the mechanisms put in place to support dereferencing of e.g. URNs will almost certainly be vulnerable to the same human-originating failure modes. > The TAG is presumably aware of this problem (having had it > pointed out to them more than once), and has presumably > decided that it does not matter enough to make a difference. > But as long as domain names are allowed to be used more > than once by different owners, no system of unique > identifiers built on the domain name system actually > guarantees uniqueness of identifier. Correct. I am unaware of _any_ examples of published standards-related URIs transitioning from useful to misleading (as opposed to useless). It's not impossible for this to happen, but pretty unlikely. I have a long-standing interest in coming up with some kind of domain-name insurance for web/internet standards . . . > In the short run, that doesn't matter. Whether it matters > in the long run depends on how long you want things to > work, and how dependent you want to be on netscape.com, > for example, continuing to denote what it once denoted. Jonathan Rees has argued, convincingly for me, that e.g. http://www.w3.org/1999/xhtml will always _denote_ the XHTML namespace, by use and precedent, _regardless_ of whether or not the w3.org website persists, or indeed even if w3.org gets reassigned to someone who starts serving pornographicly embellished caricatures of the XHTML spec. editors from that URI. . . I don't expect everyone to be convinced on _that_ point, but what _is_ true I think is that "thinks [will] work" wrt e.g. that namespace URI regardless of who owns the domain or what they put at it, because software, unlike human beings, does _not_ depend on successful retrieval from namespace URIs for proper functioning. Which brings us to Eliot's point: indeed the reason for the bit about dereferencability he quoted is that you _can't_ depend on retrieval, because namespace owners are _not_ required to support it. ht - -- Henry S. Thompson, School of Informatics, University of Edinburgh Half-time member of W3C Team 10 Crichton Street, Edinburgh EH8 9AB, SCOTLAND -- (44) 131 650-4440 Fax: (44) 131 651-1426, e-mail: ht@... URL: http://www.ltg.ed.ac.uk/~ht/ [mail really from me _always_ has this .sig -- mail without it is forged spam] -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.6 (GNU/Linux) iD8DBQFKnpHzkjnJixAXWBoRApUkAJ4vG8p93NLkk1SUQulx09y2QQFh3gCfSfuo 2qr8GNAr5ony8g47zs0CyhU= =vaad -----END PGP SIGNATURE----- |
|
|
Re: Best Practices for Establishing Namespace Name
by Andrew Welch
::
Rate this Message:
2009/9/2 Simon Cox <simon.cox@...>:
> In some situations it is good to include dates or version numbers in > namespace names. > For example, if your maintenance/governance arrangement expects new > versions, and particularly if the new versions are not compatible with older > versions. > Geography Markup Language from OGC made the mistake of keeping the same XML > namespace for several incompatible versions of GML, and this has caused > confusion. (The policy has since been fixed). > > Of course, you can choose to give your new version a completely new name and > namespace, but sometimes you want to claim continuity, or at least a common > scope, with an earlier product, but not confuse processors by having > incompatible declarations in the same target namesapce. Interesting, I would still be tempted to keep the same namespace and use a version attribute to distinguish the versions. If those versions are "compatible" or not doesn't really matter at the data level, all you need to be able to do is differentiate your elements from others with the same local name, and differentiate the versions. In "GML", where do you think the confusion came from? Unless they also changed the prefix between versions, looking at snippets of markup you would still be none the wiser. -- Andrew Welch http://andrewjwelch.com Kernow: http://kernowforsaxon.sf.net/ |
|
|
RE: Best Practices for Establishing Namespace Name
by Simon Cox
::
Rate this Message:
Andrew Welch wrote
> use a version attribute to distinguish the versions Where? The issue was that elements with the same name were defined differently in both GML 2.0 and GML 3.0, But they had the same target namespace. The differences were subtle - technical rather than conceptual - but real as far as a validating processor is concerned. The XML namespace is to all practical intents and purposes the designated identifier for 'the schema' and we had the same identifier for different things. Chaos ensues. -------------------------------------------------------- Simon Cox European Commission, Joint Research Centre, Institute for Environment and Sustainability, Spatial Data Infrastructures Unit, TP 262 Via E. Fermi, 2749, I-21027 Ispra (VA), Italy Tel: +39 0332 78 3652 Fax: +39 0332 78 6325 mailto:simon.cox@... http://ies.jrc.ec.europa.eu/simon-cox SDI Unit: http://sdi.jrc.ec.europa.eu/ IES Institute: http://ies.jrc.ec.europa.eu/ JRC: http://www.jrc.ec.europa.eu/ -------------------------------------------------------- -----Original Message----- From: xmlschema-dev-request@... [mailto:xmlschema-dev-request@...] On Behalf Of Andrew Welch Sent: Wednesday, 2 September 2009 17:54 To: Simon Cox Cc: noah_mendelsohn@...; Tsao, Scott; G. Ken Holman; Henry S. Thompson; xmlschema-dev@...; ekimber Subject: Re: Best Practices for Establishing Namespace Name 2009/9/2 Simon Cox <simon.cox@...>: > In some situations it is good to include dates or version numbers in > namespace names. > For example, if your maintenance/governance arrangement expects new > versions, and particularly if the new versions are not compatible with > older versions. > Geography Markup Language from OGC made the mistake of keeping the > same XML namespace for several incompatible versions of GML, and this > has caused confusion. (The policy has since been fixed). > > Of course, you can choose to give your new version a completely new > name and namespace, but sometimes you want to claim continuity, or at > least a common scope, with an earlier product, but not confuse > processors by having incompatible declarations in the same target Interesting, I would still be tempted to keep the same namespace and use a version attribute to distinguish the versions. If those versions are "compatible" or not doesn't really matter at the data level, all you need to be able to do is differentiate your elements from others with the same local name, and differentiate the versions. In "GML", where do you think the confusion came from? Unless they also changed the prefix between versions, looking at snippets of markup you would still be none the wiser. -- Andrew Welch http://andrewjwelch.com Kernow: http://kernowforsaxon.sf.net/ |
|
|
Re: Best Practices for Establishing Namespace Name
by C. M. Sperberg-McQueen-2
::
Rate this Message:
On 2 Sep 2009, at 09:40 , Henry S. Thompson wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > C. M. Sperberg-McQueen writes: > >> The record would not be complete without someone observing >> that it also has the disadvantage that if the domain name >> registration for [your committee] ever lapses, there is no >> guarantee that the new owner will refrain from assigning >> a new meaning to http://[your committee]/namespaces/xxx > > For sure. > > But be careful using this as an argument in favour of using URNs or > some other URI scheme -- If you don't care about dereferencing, it > doesn't matter that http://[your committee]/namespaces/xxx doesn't > dereference today, and might dereference misleadingly in some > relatively unlikely future. If you _do_ care, then the mechanisms put > in place to support dereferencing of e.g. URNs will almost certainly > be vulnerable to the same human-originating failure modes. The meaning of some identifiers is given in a way that guarantees permanence of the meaning assigned. If URLs mean things by virtue of the actions and/or intentions of their owners (which is what I understand the TAG's story to be), then when the owner changes, the meaning is necessarily subject to change. The difference at issue is not whether, when you dereference something, you get something 'misleading' or not. The issue is whether the prescribed methods for determinining the denotation of an identifier guarantee stability of denotation over time or not. On the account offered in your email, the system of using URLs as long-lived identifiers seems to depend on (a) the proposition that a URL has a given meaning just when the owner of the relevant domain assigns it that meaning, and (b) the proposition that a URL has a given meaning whenever we feel like interpreting that way, regardless of the actions of the owner of the relevant domain. The TAG may have no trouble reconciling those two propositions; I confess that to me, they just look like a contradiction at the heart of the TAG's edifice. -- **************************************************************** * C. M. Sperberg-McQueen, Black Mesa Technologies LLC * http://www.blackmesatech.com * http://cmsmcq.com/mib * http://balisage.net **************************************************************** |
|
|
RE: Best Practices for Establishing Namespace Name
by Simon Cox
::
Rate this Message:
I agree with Michael.
The fact that there is no general URN resolution service (besides reading the relevant RFCs) is highly inconvenient and pragmatically it is a killer. But the fact that URN assignment is onerous (much much much more onerous than URL creation) is not necessarily a bad thing. Some resources really are more valuable than others, and having a high threshold in the identifier assignment process reinforces this. I think I understand the Thompson/TAG argument that the same discipline *could* be applied to http URIs, but in general it is not ... which leaves us in this maybe/maybe not situation. -------------------------------------------------------- Simon Cox European Commission, Joint Research Centre, Institute for Environment and Sustainability, Spatial Data Infrastructures Unit, TP 262 Via E. Fermi, 2749, I-21027 Ispra (VA), Italy Tel: +39 0332 78 3652 Fax: +39 0332 78 6325 mailto:simon.cox@... http://ies.jrc.ec.europa.eu/simon-cox SDI Unit: http://sdi.jrc.ec.europa.eu/ IES Institute: http://ies.jrc.ec.europa.eu/ JRC: http://www.jrc.ec.europa.eu/ -------------------------------------------------------- -----Original Message----- From: xmlschema-dev-request@... [mailto:xmlschema-dev-request@...] On Behalf Of C. M. Sperberg-McQueen Sent: Wednesday, 2 September 2009 18:53 To: Henry S. Thompson Cc: C. M. Sperberg-McQueen; Tsao, Scott; G. Ken Holman; xmlschema-dev@... Subject: Re: Best Practices for Establishing Namespace Name On 2 Sep 2009, at 09:40 , Henry S. Thompson wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > C. M. Sperberg-McQueen writes: > >> The record would not be complete without someone observing that it >> also has the disadvantage that if the domain name registration for >> [your committee] ever lapses, there is no guarantee that the new >> owner will refrain from assigning a new meaning to http://[your >> committee]/namespaces/xxx > > For sure. > > But be careful using this as an argument in favour of using URNs or > some other URI scheme -- If you don't care about dereferencing, it > doesn't matter that http://[your committee]/namespaces/xxx doesn't > dereference today, and might dereference misleadingly in some > relatively unlikely future. If you _do_ care, then the mechanisms put > in place to support dereferencing of e.g. URNs will almost certainly > be vulnerable to the same human-originating failure modes. The meaning of some identifiers is given in a way that guarantees permanence of the meaning assigned. If URLs mean things by virtue of the actions and/or intentions of their owners (which is what I understand the TAG's story to be), then when the owner changes, the meaning is necessarily subject to change. The difference at issue is not whether, when you dereference something, you get something 'misleading' or not. The issue is whether the prescribed methods for determinining the denotation of an identifier guarantee stability of denotation over time or not. On the account offered in your email, the system of using URLs as long-lived identifiers seems to depend on (a) the proposition that a URL has a given meaning just when the owner of the relevant domain assigns it that meaning, and (b) the proposition that a URL has a given meaning whenever we feel like interpreting that way, regardless of the actions of the owner of the relevant domain. The TAG may have no trouble reconciling those two propositions; I confess that to me, they just look like a contradiction at the heart of the TAG's edifice. -- **************************************************************** * C. M. Sperberg-McQueen, Black Mesa Technologies LLC * http://www.blackmesatech.com * http://cmsmcq.com/mib * http://balisage.net **************************************************************** |
|
|
Re: Best Practices for Establishing Namespace Name
by Andrew Welch
::
Rate this Message:
2009/9/2 Simon Cox <simon.cox@...>:
> Andrew Welch wrote >> use a version attribute to distinguish the versions > > Where? Typically on the root element, but it could go anywhere that's suitable. > The issue was that elements with the same name were defined differently in > both GML 2.0 and GML 3.0, > But they had the same target namespace. The differences were subtle - > technical rather than conceptual - but real as far as a validating processor > is concerned. The XML namespace is to all practical intents and purposes the > designated identifier for 'the schema' and we had the same identifier for > different things. Chaos ensues. Between versions the content model of elements will change, but that doesn't mean you need a different namespace... Incompatible changes are actually easier than supporting backwards compatibility, instead of detecting the version and using the right xsd and corresponding parsing code, you simply reject anything that fails validation for that version. Anyway, it's interesting that you say the namespace is (to all intents ands purposes) the identifier for the schema, perhaps that's where the problem is... the namespace value itself has started to mean something, when its meant to mean nothing. Everyone seems to have different opinions on this, and I think Ive asked in the past if anyone has a best practices guide which didnt attract too many confident replies, but at the moment for me its simply "namespace that won't ever change, version attribute" : ) -- Andrew Welch http://andrewjwelch.com Kernow: http://kernowforsaxon.sf.net/ |
|
|
RE: Best Practices for Establishing Namespace Name
by Simon Cox
::
Rate this Message:
No - its not merely the identity issue.
Its the processing issue. A processors will maintain a cache of schema component definitions and declarations and associate it with a namespace. The processing rules in the XML Schema spec do not require that a processor load the schema fresh if a new document comes in with the same namespace. So if the new document is actually using a different schema (even if the namespace is the same) then processing will fail. The only way to ensure safe processing (i.e. that respects *all* of the processing straegies allowed for in the XML Schema spec) is to be scrupulous about changing namespace if the schema changes. In many cases that is most easily handled by including a version identifier in the namespace. Because of all this, the XML Schema processing rules effectively imply that the target namespace is the schema identifier. -------------------------------------------------------- Simon Cox European Commission, Joint Research Centre, Institute for Environment and Sustainability, Spatial Data Infrastructures Unit, TP 262 Via E. Fermi, 2749, I-21027 Ispra (VA), Italy Tel: +39 0332 78 3652 Fax: +39 0332 78 6325 mailto:simon.cox@... http://ies.jrc.ec.europa.eu/simon-cox SDI Unit: http://sdi.jrc.ec.europa.eu/ IES Institute: http://ies.jrc.ec.europa.eu/ JRC: http://www.jrc.ec.europa.eu/ -------------------------------------------------------- -----Original Message----- From: Andrew Welch [mailto:andrew.j.welch@...] Sent: Wednesday, 2 September 2009 19:18 To: Simon Cox Cc: noah_mendelsohn@...; Tsao, Scott; G. Ken Holman; Henry S. Thompson; xmlschema-dev@...; ekimber Subject: Re: Best Practices for Establishing Namespace Name 2009/9/2 Simon Cox <simon.cox@...>: > Andrew Welch wrote >> use a version attribute to distinguish the versions > > Where? Typically on the root element, but it could go anywhere that's suitable. > The issue was that elements with the same name were defined > differently in both GML 2.0 and GML 3.0, But they had the same target > namespace. The differences were subtle - technical rather than > conceptual - but real as far as a validating processor is concerned. > The XML namespace is to all practical intents and purposes the > designated identifier for 'the schema' and we had the same identifier > for different things. Chaos ensues. Between versions the content model of elements will change, but that doesn't mean you need a different namespace... Incompatible changes are actually easier than supporting backwards compatibility, instead of detecting the version and using the right xsd and corresponding parsing code, you simply reject anything that fails validation for that version. Anyway, it's interesting that you say the namespace is (to all intents ands purposes) the identifier for the schema, perhaps that's where the problem is... the namespace value itself has started to mean something, when its meant to mean nothing. Everyone seems to have different opinions on this, and I think Ive asked in the past if anyone has a best practices guide which didnt attract too many confident replies, but at the moment for me its simply "namespace that won't ever change, version attribute" : ) -- Andrew Welch http://andrewjwelch.com Kernow: http://kernowforsaxon.sf.net/ |
|
|
Re: Best Practices for Establishing Namespace Name
by Henry S. Thompson
::
Rate this Message:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1 C. M. Sperberg-McQueen writes: > The meaning of some identifiers is given in a way that > guarantees permanence of the meaning assigned. I'm very interested in examples of this for identifiers useable on the web, particularly ones which participate in what's been informally called the 'follow your nose' property, or, per [1], "grounded in the Web": the specifications required for their interpretation should be discoverable by recursively following links starting with the specification for URIs [rfc 3986]. > If URLs mean things by virtue of the actions and/or intentions of > their owners (which is what I understand the TAG's story to be), > then when the owner changes, the meaning is necessarily subject to > change. Indeed. As I said in my previous message, diligence is required to forestall this, and it's not unreasonable to expect/mandate diligence in cases where long-term persistence is a high-level goal. > The difference at issue is not whether, when you dereference > something, you get something 'misleading' or not. The > issue is whether the prescribed methods for determinining > the denotation of an identifier guarantee stability of > denotation over time or not. > On the account offered in your email, the system of using > URLs as long-lived identifiers seems to depend on (a) the > proposition that a URL has a given meaning just when the > owner of the relevant domain assigns it that meaning, and > (b) the proposition that a URL has a given meaning > whenever we feel like interpreting that way, regardless > of the actions of the owner of the relevant domain. > > The TAG may have no trouble reconciling those two > propositions; I confess that to me, they just look like > a contradiction at the heart of the TAG's edifice. Insofar as the TAG is in a position to prescribe anything in this area, (1) is indeed the official story (actually, it's RFC 3986 which _prescribes_ in this case). Your (2) is a lot stronger than what I said, which was in any case _not_ a TAG position, or even anyone's proposal of a _possible_ position, but rather an empirical _claim_, with respect to a small number of very widely deployed namespace URIs. _If_ that claim is true, that means that the world is not behaving as has been 'prescribed'. There is in fact a lively debate underway about a variety of possible accounts of URIs and how they identify things, which may or may not succeed in reconciling theory and practice in a useful way. The relevance of all this to the issue at hand is, I think, not very great. As long as the purpose of creating namespace URIs at all involves a) at least the possibility of value-add from web-access via the namespace URI; b) a commitment to diligence wrt any registrations which underlie whatever web-access mechanisms are in prospect. then my advice stands -- http: URIs have a clear advantage over any other form of URI. ht [1] http://www.w3.org/2001/tag/doc/selfDescribingDocuments.html - -- Henry S. Thompson, School of Informatics, University of Edinburgh Half-time member of W3C Team 10 Crichton Street, Edinburgh EH8 9AB, SCOTLAND -- (44) 131 650-4440 Fax: (44) 131 651-1426, e-mail: ht@... URL: http://www.ltg.ed.ac.uk/~ht/ [mail really from me _always_ has this .sig -- mail without it is forged spam] -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.6 (GNU/Linux) iD8DBQFKnrh2kjnJixAXWBoRAixbAJ9zvrSVB2lcfHZLCS0ps9/kG18XxgCdFBlA qop9GJB3IifZ9Lz4iHR1ekQ= =6IOi -----END PGP SIGNATURE----- |
|
|
RE: Best Practices for Establishing Namespace Name
by Peter Geraghty
::
Rate this Message:
Andrew says 'Unless they also changed the prefix between versions,
looking at snippets of markup you would still be none the wiser'. From the perspective of automated processing of XML this is beside the point. A program processing XML does not look at snippets of markup (and anyway the prefix is not defined by the schema and in a "snippet" without namespace bindings the prefix has no meaning). If a namespace relates to a particular version of a schema, it provides an unambiguous indication of which schema should be used by a processor. If a version attribute has to be considered as well, the processor needs some knowledge of the convention used for versioning within that particular namespace. For this there is no standard. This email chain has brought into new focus a concern I had about the rationale for the Schema 1.1 "Open Content" enhancements. There is an implied expectation behind these that schemas will change without any change in their namespace, and this is arguably not "best practice", since it implies a non-standard versioning mechanism. The idea behind these enhancements is that a message producer can move to a "Level 2" version of a schema, which defines more precisely what in the "Level 1" version would have been possible by use of wildcards, whilst message consumers who are unaware of "Level 2" can continue to process messages from such producers. If the namespace were to change as part of the move from "Level 1" to "Level 2" the intention of the enhancements (that some consumers can remain unaware of the change) would be defeated. I think there is an important consideration that if there many bodies producing messages some may move to "Level 2" while others are at "Level 1". A message consumer may be aware of both "Level 1" and "Level 2" versions of the schema and may need to know which version to apply when processing a message received, e.g., for either or both of the following reasons: (a) The set of messages acceptable under "Level 2" may be smaller than that acceptable under "Level 1". If the processor is responsible for validation, it needs to know which level to use for validation. (b) Typically a "Level 2" schema will have been a response to a need to communicate additional information, and it is a common situation that de facto this information was being sent between parties by means of wildcards under "Level 1". It is likely that the convention for this would not correspond exactly to the formal definitions introduced in "Level 2". Therefore the processor may have to look in different places to find equivalent information depending on which version of the schema the message producer was using. Therefore to be used in an environment where messages are produced by multiple parties and are processed automatically by recipients, the "open content" enhancements imply that some kind of version attribute is available to processors, and to my mind it is a weakness that the schema standard implies versioning changes within a namespace without defining or even mentioning how versioning can be communicated if not by namespace change. Or putting this more strongly, it could be argued that the "open content" enhancements are predicated on "bad practice" in terms of URN assignment. Pete -----Original Message----- From: xmlschema-dev-request@... [mailto:xmlschema-dev-request@...] On Behalf Of Andrew Welch Sent: 02 September 2009 16:54 Interesting, I would still be tempted to keep the same namespace and use a version attribute to distinguish the versions. If those versions are "compatible" or not doesn't really matter at the data level, all you need to be able to do is differentiate your elements from others with the same local name, and differentiate the versions. In "GML", where do you think the confusion came from? Unless they also changed the prefix between versions, looking at snippets of markup you would still be none the wiserDisclaimer: The contents of this E-mail plus any attachment is intended for the use of the addressee only and is confidential, proprietary and may be privileged. It will not be binding upon Trace Group or any group company (Trace). Opinions, conclusions, contractual obligations and other information in this message in so far as they relate to the official business of Trace must be specifically confirmed in writing by Trace. If you are not the intended recipient you must not copy this message or attachment, use or disclose the contents to any other person, but are requested to telephone or E-mail the sender and delete the message and any attachment from your system. Trace takes all reasonable precautions to ensure that no virus or defect is transmitted via this e mail, however Trace accepts no responsibility for any virus or defect that might arise from opening this E-mail or attachments. |
|
|
RE: Best Practices for Establishing Namespace Name
by Tsao, Scott
::
Rate this Message:
Henry, Thanks for the
confirmation!
Is this the document you were
referring to as far as W3C TAG's strong recommendation is concerned: http://www.w3.org/2001/tag/doc/URNsAndRegistries-50 ?
Scott
-----Original Message----- From: Henry S. Thompson [ht@...] Sent: Wednesday, September 02, 2009 2:40 AM To: Tsao, Scott Cc: G. Ken Holman; xmlschema-dev@... Subject: Re: Best Practices for Establishing Namespace Name -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 ... > And, is the use of them for namespace names (in lieu of URN) > recommended by standards organizations such as W3C and OASIS? Absolutely. OASIS have backed off using URNs as namespace names, and W3C TAG strongly recommends using http: URIs for this purpose. ... ht - -- Henry S. Thompson, School of Informatics, University of Edinburgh Half-time member of W3C Team 10 Crichton Street, Edinburgh EH8 9AB, SCOTLAND -- (44) 131 650-4440 Fax: (44) 131 651-1426, e-mail: ht@... URL: http://www.ltg.ed.ac.uk/~ht/ [mail really from me _always_ has this .sig -- mail without it is forged spam] -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.6 (GNU/Linux) iD8DBQFKnj1akjnJixAXWBoRAgpnAJ946RWeMWRT4NA3S1hHT0bCc63GPgCcDCJp 3NNY0Glqx4E0BJeWcEZs0z8= =zpxU -----END PGP SIGNATURE----- |
| < Prev | 1 - 2 | Next > |
| Free embeddable forum powered by Nabble | Forum Help |
