restructuring Purls to reflect version number?
- Hi all,
Can we structure the module Purls (and their URI usage) to reflect their version
Arguments about this being a 'bad idea' have certainly been considered and we'll
doubltlessly have a few more. I'm looking to provide someone new to handling
our modules and the corresponding namespaces with a way to /dependably/ extract
a version number. Soley to aid them in being confident in that they're handling
the contents in a manner they base on their understanding of a given modules'
We could also state that if the a new module number, perhaps, doesn't deprecate
or otherwise fundamentatlly change the nature of it's previous version then no
major number change should be used. That way someone coming across the, say,
1.2 version of the module, knowing only the 1.1 feature set might be able to
continue using the previous handling techniques (while presumably squawking
about it to the user). But coming across 2.0 knowing only 1.1 would mean
significant changes, possibly causing breakage, have occurred. Similarly,
notification of the user is warranted but processing attempts should probably
Let's not get too bogged down arguing nuances of version number schemes. I'd
like to see us follow an /easy to handle/ numeric setup. Giving the reader
programs a way to detect versions as /simply/ as possible would suggest we avoid
descending into 1.1.1b1 sort of foolishness, but I'm willing to be convinced
Is there and merit to separating the Modules from under the rss/1.0 hierarchy?
Or is there sufficient reason to keep the modules nested in this hierarchy?
Regardless of movement in/out of the rss/1.0 hierarchy, can we go about getting
the purls for each of them to reflect the actual module version number?
Starting at 1.0 if needed, or 0.whatever for proposed ones, etc.
- On Tue, 10 Sep 2002, Leigh Dodds wrote:
> Following up on my own postingA very late input on this, but how about (2) with the addition of (2a)
> How do module versions and namespaces interact. Seems like
> there are two options:
> 1. never change the NS URI
> 2. change the NS URI with major module versions
> I think 1. goes against the basic principle of namespaces, although that
> might be open to interpretation. Anyone have any thoughts?
2a. use schemaLocation attributes to specify the specific schemas that
apply to an RSS instance document.
That's a standard XML schema mechanism, and provides, after a fashion,
an additional level of version information.
There was discussion on XML-DEV of how you can use this mechanism to
convey information about multiple namespaces and associated schemas. For
xsi:schemaLocation="[ns1] [schema1] [ns2] [schema2] ... "
where the value is a set of tuples, each tuple consisting of a nsURI and
the URI referencing the associated schema file.