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

[Anne Hendry <anne.hendry@sun.com>]

Hi Jon,

Further comments inline.

jon.bosak@sun.com wrote

>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.
>
Oh, ok.  I'm not understanding the use of the URL then.  I thought the 
final resting place of the schemas would be the URL in NM6.  If not, 
then my argument doesn't apply (and I'll get someone to explain later).

>David changes the codelist filenames to remove "CodeList-" and
>runs the generator again, right?  Am I missing something?
>
Perhaps.  It's my understanding that David would change some value in 
the tool (a programmatic change).  If that's not the case, still, any 
change to the schemas introduces the possibility of another error (most 
new errors are introduced by last-minute minor changes).  It's my view 
that any change to the schemas should be accompanied by a final test run 
(XMLSpy, etc).  And I'm not sure, but it seems this might require a new 
run of the asn.1 schemas.  I don't think there should be any more 
changes to the schemas unless there is some catastrophic problem with 
what we have now.  This just doesn't seem like a big enough problem to 
me.  Is there something I'm missing?

>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.
>
Does this mean to say that we don't need nm6 if the catalog mappings are 
available?  Should we instead be working on having the catalog mappings 
created?  Although I can see how these two relate, not knowing exactly 
what the catalog looks like, I'm not sure how this would be addressed.

>| 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.
>
Well, yes, of course.  What I was trying to say, obviously not clearly 
enough, was that I don't see why nm6 has to use the same 
convention/components/terms as nm5.

>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.
>
Yes, so I think a rule change would be the most obvious conclusion.

>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
>
Yes!   Me too (I'll go for #3).

>
>   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.
>
No, no, no, no to 1 and 2.  So far we've tried very, very hard not to 
change the schemas again.  I think this is just not a big enough 
problem, and as you point out, we don't even know if it is a problem. 
 Obviously this rule needs more scrutiny.

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

-A