[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: CodeList in document-id (was: CD2 sanity check)
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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]