OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

ubl message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


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


[anne.hendry@sun.com:]

| I think your example points out another problem.  I hadn't looked
| at NM6 all that closely until now.  Does NM6 necessarily follow
| from NM4 and NM5?  Because if we follow the naming as it is in
| NM6, 'subtype' will always be 'xsd' and we would have to have all
| schemas under a directory names 'xsd'

Not necessarily.  The NDR work team in Copenhagen left out part of
NMS6 that was adopted by email before the meeting.  That version,
posted on 7 August 2004, reads as follows:

   [NMS6] UBL Schema modules MUST be hosted under the OASIS UBL
      Technical Committee directory at the URL

      http://www.oasis-open.org/committees/ubl/schema/<subtype>/UBL-<document-id>.<filetype>

   where <document-id> follows the UBL rules for UBL RFC 3121
   document-ids, <subtype> refers to a token specifying the
   schema language (currently one of "xsd", "rng", and "asn1"),
   and <filetype> refers to the file format ("xsd", "rng",
   "html", etc.) used to store the schema at that location.

The version in the document posted by the team leaves out all the
qualifying language following the syntax format.  If you include
this, then it's clear that subtype is not always "xsd" but can
sometimes be "rng" or "asn1".  But I take your point:

| since there is no space in the NM6 pathname for the
| subdirectories we now use to organize the schemas: 'common',
| 'codelist', and 'maindoc'.

You're right.  Rule NMS6 in both the current NDR and in the draft
of 10 March 2004 leaves out the "common", "codelist", and
"maindoc" subdivisions, so this apparent contradiction has been
with us for a while.

| Here is an example from the AcknowledgementResponseCode' schema:
| 
|    <xsd:import namespace="urn:oasis:names:specification:ubl:schema:xsd:CoreComponentParameters-1.0" schemaLocation="../common/UBL-CoreComponentParameters-1.0.xsd"/>
| 
| If we followed NM6 then we will also need to redo the package
| structure to remove the subdirectories 'common', 'codelist', and
| 'maindoc', and leave all schemas in the 'xsd' directory only.

I don't think there's any rule that says the persistent URL at
OASIS has to have the same structure as the package.  I can see
why one might be uncomfortable with the difference, but if we
follow the logic that led us to leave out the version number from
the part of the URN that says "ubl", then in fact a great big xsd
directory containing all the past and current versions of the xsd
schemas is probably just what we want.  Consider the case we
discussed in Copenhagen where we've kept a future Foo-1.5.xsd in a
future UBL 2.0 package.  We want the canonical OASIS copy of the
UBL-Foo-1.5.xsd file to stay exactly where we put it when we published
UBL 1.5, viz., at the URL

   http://www.oasis-open.org/committees/ubl/schema/xsd/UBL-Foo-1.5.xsd

where it will stay with its friends UBL-Bar-1.5.xsd (etc.) from
the UBL 1.5 release along with new neighbors from the 2.0 package
named UBL-Bar-2.0.xsd (etc.) and may someday be joined by a newer
version such as UBL-Foo-3.1.4.xsd.  In other words, in deciding to
disconnect the schema versioning from the release packages, we
eliminated the need to reflect the package structure in the schema
repository (which in fact we haven't been trying to do anyway).  I
didn't fully realize that this was our plan at the time the
earlier drafts of the NDRs were developed, but I think I'm OK with
it, particularly since I view the whole persistent URL mechanism
of NMS6 as a temporary dodge around the current lack of a genuine
URN resolution mechanism.

The part I'm not OK with is having "CodeList" be part of the
document-id in the URN and but not part of document-id in the
URL.  I think that our previous decision to leave it out of the
URN means that we have to leave it out of the URL.  In any event,
this must be decided one way or the other in our meeting of 1
September (which unfortunately I cannot attend) so that we can run
the schemas one more time and I can publish a final sanity check
including both the revised schemas and the revised /fs directory
this weekend.

Jon

   Date: Sun, 29 Aug 2004 22:09:10 -0700
   From: Anne Hendry <anne.hendry@sun.com>
   CC: ubl@lists.oasis-open.org

   Hi Jon,

   I think your example points out another problem.  I hadn't looked at NM6 
   all that closely until now.  Does NM6 necessarily follow from NM4 and 
   NM5?  Because if we follow the naming as it is in NM6, 'subtype' will 
   always be 'xsd', and we would have to have all schemas under a directory 
   names 'xsd', since there is no space in the NM6 pathname for the 
   subdirectories we now use to organize the schemas: 'common', 'codelist', 
   and 'maindoc'.

   Here is an example from the AcknowledgementResponseCode' schema:

   <xsd:import 
   namespace="urn:oasis:names:specification:ubl:schema:xsd:CoreComponentParameters-1.0" 
   schemaLocation="../common/UBL-CoreComponentParameters-1.0.xsd"/>

   If we followed NM6 then we will also need to redo the package structure 
   to remove the subdirectories 'common', 'codelist', and 'maindoc', and 
   leave all schemas in the 'xsd' directory only.

   So my question is whether there is a benefit in the specific pathname 
   being specified by NM6 over the schemaLocation we currently use?  Is 
   there some reason for us to change the package current structure to 
   match NM6?  Does NM6 add more value than the cost of adhering to it in 
   it's current form?  Is it the package that should change, or the rule? 
    NM6 says 'the UBL modules must be hosted ...'  Is there any reason for 
   NM6 to specify the pathname beyond the word 'schema' (ie. past 
   http://www.oasis-open.org/committees/ubl/schema/)?

   -A

   jon.bosak@sun.com wrote:

   >[stephen_green@seventhproject.co.uk:]
   >
   >| This would require changes to the Schemas (the imports of the
   >| codelist Schemas) so I'm not sure it would be worth such changes
   >| since it may affect others downstream.
   >
   >Yeah, well, I'm sorry, but it's clear to me now that our final
   >naming and design rules require it.  Here are our rules:
   >
   >   [NMS4] The namespace names for UBL Schemas holding committee
   >   draft status MUST be of the form:
   >
   >      urn:oasis:names:tc:ubl:schema:<subtype>:<document-id>
   >
   >   [NMS5] The namespace names for UBL Schemas holding OASIS
   >   Standard status MUST be of the form:
   >
   >      urn:oasis:names:specification:ubl:schema:<subtype>:<document-id> 
   >
   >   [NMS6] UBL Schema modules MUST be hosted under the UBL
   >   committee directory:
   >
   >      http://www.oasis-open.org/committees/ubl/schema/<subtype>/UBL-<document-id>.<filetype>
   >
   >Now look at Anne's example:
   >
   >   <xsd:import namespace="urn:oasis:names:specification:ubl:schema:xsd:CurrencyCode-1.0" schemaLocation="../codelist/UBL-CodeList-CurrencyCode-1.0.xsd"/>
   >
   >Clearly by NMS5 the document-id in the namespace attribute is
   >"CurrencyCode-1.0", but just as clearly by NMS6 the document-id in
   >the schemaLocation attribute is "CodeList-CurrencyCode-1.0".  One
   >of these is wrong.
   >
   >Jon


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]