Summarizing restructuring Purls to reflect version number
- I'm gathering from everyone's feedback that using a stable URI to start with is
an important thing.
If we advance guidelines that indicate the helpful nature of using versioned
URIs that'd be a good start. Then using an optional prefix:version element
would help a module indicate variations within it's parent namespace. This too
could be advanced as a 'best practice' guideline. The thought being the reader
tool developers could remain aware that a version element could appear and might
affect their use of the module's content. And that a variation in the namespace
URI would indicate that significant enough changes have occurred as to warrant
further updating in the reader environment.
At the same time as Jon has pointed out, the RDF schemata for these things does
have some nice framework for helping programs that care to do the digging ways
to find out much more factual information about what's really happening. The
hassle being that many modules currently lack such schemata. It would help if
we advanced the idea that doing a schema is more than just a trivial thing and
is well worth having for a module.
So at this point I'm left with this:
Pick a good URI and trail it with a version string. Do not alter that string
for subtle format additions. Alter that string only on changes that would
significantly affect the parsing of the module contents. Warning, of course,
that variations put upon this namespace cause complications downstream that are
much harder to fix that one might anticipate.
If needed, put an optional prefix:version string in the feed that contains the
actual variation used within the namespace URI.
This raises some questions as well. Should the format of said string being
closely modelled on user-agent as used in Mozilla? And 'where' in the feed
should a module put this element? As in, where should a reader program expect
to find such elements?
We're also left with the question of using versions on a per-item basis. How
would we want to speak of that practice? It's certainly legal to do it but
reader programs are most likely completely unprepared to handle it properly.
- Hi (Bill),
On Wednesday 11 September 2002 15:20, you wrote:
> If needed, put an optional prefix:version string in the feed that contains
> the actual variation used within the namespace URI.
> This raises some questions as well. Should the format of said string being
> closely modelled on user-agent as used in Mozilla? And 'where' in the feed
> should a module put this element? As in, where should a reader program
> expect to find such elements?
May I suggest going with the idea of RDF, as in:
If you happen to have that URI formatted as a superstring of the namespace
URI, you have subversioning...
This model would of course be optional, as long as they are URIs (and perhaps
URLs) , I don't see a reason for a specifiec format, except for human reading
-- they shoud never be parsed.