Loading ...
Sorry, an error occurred while loading the content.
 

restructuring Purls to reflect version number?

Expand Messages
  • Bill Kearney
    Hi all, Can we structure the module Purls (and their URI usage) to reflect their version number? Arguments about this being a bad idea have certainly been
    Message 1 of 54 , Sep 10, 2002
      Hi all,

      Can we structure the module Purls (and their URI usage) to reflect their version
      number?

      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'
      namespace URI.

      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
      cease.

      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
      otherwise.

      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.

      Thanks,
      Bill Kearney
    • Ian Graham
      ... A very late input on this, but how about (2) with the addition of (2a) 2a. use schemaLocation attributes to specify the specific schemas that apply to an
      Message 54 of 54 , Sep 21, 2002
        On Tue, 10 Sep 2002, Leigh Dodds wrote:

        > Following up on my own posting
        >
        > 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?

        A very late input on this, but how about (2) with the addition of (2a)

        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
        example:

        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.

        Ian
      Your message has been successfully submitted and would be delivered to recipients shortly.