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: [ubl] Re: CodeList in document-id (was: CD2 sanity check)


jon.bosak@sun.com wrote:

>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:
>
Thanks for highlighting this - it needed clarification

>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.
>
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, but your point is 
well taken on future usability.  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.

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?

>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.
>
I don't see why the filename convention has to follow the urn 
convention.  They're totally separate things - related, but separate. 
 There is a completely separate oasis convention for file names, and 
what we're tripping over here with nm6, more importantly, is actually a 
file path, not even a file name.  That's not to say that I think we need 
to leave 'codelist' in the file name, as I agree it's redundant, but 
more importantly, if we're discussing the overall approach, then  if NM6 
doesn't specify anything beyond the 'schema' component we have no rule 
problem.  If we are decoupling, as you've noted above, it is a separate 
issue (as long as the file name follows the OASIS file naming convention 
- although we don't seem to have a rule for that).  The text preceding 
NM6 states that 'UBL schema locations will differ from UBL namespace 
declarations'.  So why is the URL structured like the namespace URN 
rather than according to decisions on how to structure the path and 
filenames (a discussion I don't think we've really delved into until now).

My concern was much more with nm6 specifying past 'schema'.  I don't see 
why there needs to be a rule specifying our file structure down to the 
file name, since there is already a convention specified by oasis for 
file names and the locations below schema may in the future have some 
need to be distinguished regardless of the outcome of the proposal you 
make above (it seems we're having the same discussion now that we had 
for nm5 but now we're on filenames and filepaths as opposed to urns!)

My proposal would be to stop nm6 after the document type (in this case, 
'schema'), but seriously consider the current package structure for 
future usability as in your suggestion to flatten the heirarchy.

-A

>
>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
>
>To unsubscribe from this mailing list (and be removed from the roster of the OASIS TC), go to http://www.oasis-open.org/apps/org/workgroup/ubl/members/leave_workgroup.php.
>
>  
>




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