Re: CodeList in document-id (was: CD2 sanity check)

[jon.bosak@sun.com]

I'm writing this without having seen today's mail on the subject
(if any), and I won't be picking up mail again until September 5
or 6, so this will have to be all I can contribute to tomorrow's
discussion.

[anne.hendry@sun.com:]

| Interesting.  I think this is certainly something we should
| discuss Wednesday.  It would require redoing all schemas that have
| an import from another directory, and the package structure

I don't see anything that would require us to change the package
structure.  My point was that the package structure is independent
of the persistent URL.  I think we can leave the package structure
out of this.

| At the moment I can't think of any problems it might raise for the
| future, but it certainly raises some for the present schedule.

David changes the codelist filenames to remove "CodeList-" and
runs the generator again, right?  Am I missing something?

| Regarding your last statement, in looking at RFC 3121 it doens't 
| specifically address persistent URLs, but there is this bit:
| 
|    Process of identifier resolution:
| 
|       The owner will distribute catalogs (OASIS TR9401 Catalogs) that
|       map the assigned URNs to resource identifiers (e.g., URLs).  A
|       more interactive, online resolution system will also be deployed
|       in the near future.
| 
|       The owner will authorize additional resolution services as
|       appropriate.
| 
| Do we need to do anything for this?

I don't think *we* do; "owner" here means OASIS administration.
But it seems to me that the construction of such a catalog would
accomplish exactly what NMS6 is trying to accomplish.

| I don't see why the filename convention has to follow the urn
| convention.

Because NMS6 says it does.  There is something called
"document-id" in there that has to be the same thing as the
"document-id" used in NMS4, NMS5, VER1, VER2, VER3, and VER4.  If
document-id used in connection with code lists contains
"CodeList-", then it contains "CodeList-" everywhere that
document-id appears.  If it doesn't, then it doesn't.  Flip a
coin... whatever... but according to the NDRs as presently
written, "document-id" appears in all seven syntax rules and
therefore has to contain the same string when referring to the
same schema.

Another alternative, of course, is to change or delete NMS6 (which
I now believe to be redundant given the TR9401 catalog mentioned in
the passage Anne cites above).  So I think the choices the TC
needs to run through tomorrow are:

   1. Remove "CodeList-" from all the code list file names and run
      the schema generator again, or

   2. Include "CodeList-" in all the code list URNs and run the
      schema generator again, or

   3. Delete NMS6 from the current NDR checklist, leave the
      schemas the way they are, and take a little additional time
      to figure out what NMS6 should actually say or whether it's
      even necessary (I personally would prefer this, as it's
      clear that the form I suggested a couple of weeks ago did
      not get the depth of scrutiny I was hoping for), or

   4. If it's relatively easy to perform either 1 or 2 (meaning
      that it wouldn't take more than a day and David is available
      to do it), do 3 on the grounds that NMS6 is insufficiently
      cooked and needs more thought before we approve the NDR CD
      *and also* do either 1 or 2.

An alternative that is available in theory but would in my opinion
be highly inadvisable is

   5. Rewrite NMS6 in tomorrow's TC call based on no more
      discussion than what we've had so far (for example, yank out
      "document-id" and put in something hacky that lets us keep
      our schemas unchanged).

I would strongly discourage that one, but I suppose it's possible.

The alternative that is NOT available is

   6. Use the token "document-id" in seven closely related syntax
      rules but have it represent something different in one of
      them than it represents in the other six.

That one won't fly at all.

Jon