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] Including code list schemas in the UBL package


I received this message after the Atlantic call began and
therefore didn't see it until the call had ended.

> It has been suggested to me off-list [...]

Which means that we have no formal responsibility to recognize
this as an issue.  So I'm treating this as a question from Ken.

| Summary:
| 
| (1) - should the UBL 2.0 delivery include copies of the genericode
| XSD files?
| 
| (2) - should the UBL 2.0 genericode files point 
| to these XSD files using xsi:schemaLocation with a relative URL?
| 
| My answers are: (1) - yes, and (2) - no.

I completely agree with (2), but I would say No to (1).  While
this has no substantive impact on the specification, I can't see
any good reason to put yet more stuff into the release.  It just
means more to confuse people and more to document.  At the least,
people are going to assume that the added files are normative in
some sense, which isn't true at this point even for genericode.
Weren't we going to include the genericode xsd files in the
Support Package anyway?

Jon

   Date: Wed, 30 Aug 2006 10:27:46 -0400
   From: "G. Ken Holman" <gkholman@CraneSoftwrights.com>

   Hi folks,

   Two weeks ago in Montréal we decided to remove 
   xsi:schemaLocation from UBL instances since it 
   wasn't up to one UBL trading partner to say where 
   the XSD files are going to be for another trading 
   partner in their different environment.  Imagine 
   the problems if Trading Partner A pointed their 
   UBL instances to "c:\tpa\ubl\invoice.xsd" and 
   Trading Partner B has installed UBL schemas in 
   "d:\tpb\ubl2\schemas\invoice.xsd".  It doesn't 
   make sense to include xsi:schemaLocation, and in 
   fact I think (and it was agreed) this was actually harmful.

   I personally think this applies to the genericode 
   files as well, since users of the code list 
   methodology will probably be taking the code 
   lists out of the context of the UBL directories 
   and putting them in their own contexts for management.

   It has been suggested to me off-list that in UBL 
   2.0 we should include the genericode XSD files in 
   the directories and point each of the genericode 
   files in the UBL 2.0 delivery to those XSD files 
   using xsi:schemaLocation using relative paths.

   While I disagree with this, it isn't up to me to decide alone.

   I think it is not a good practice for XML files 
   to point to the schema used for their validation, 
   since this is a system issue and not a data issue.

   I admit some editing tools rely on 
   xsi:schemaLocation in order to implicitly 
   associate document models with document instances 
   to make editing easier, but I don't feel this is 
   sufficient argument to impact on the integrity of 
   the data files.  While it may help in a limited 
   case, it will cause problems when the files are 
   moved for system decisions that have nothing to do with the data itself.

   The more we do to allow our resources to be read 
   only and to not have to be touched in order to 
   reflect system choices that are arbitrary for 
   users, I think the better ... so I really do feel 
   strongly our genericode files (and all of our 
   files) should not have xsi:schemaLocation.

   I would support including the code list XSD files 
   somewhere in the cl/ directory so that users have 
   a copy of the document model actually in play 
   when the genericode files were created 
   (especially since genericode is being revised), 
   but I don't think we should point to those files 
   from inside the delivered genericode resources.

   Could this question please be asked at the 
   Atlantic call?  I am unable to attend in order to 
   defend my point, so I hope the above is sufficient to present my concerns.

   Summary:

   (1) - should the UBL 2.0 delivery include copies of the genericode XSD files?

   (2) - should the UBL 2.0 genericode files point 
   to these XSD files using xsi:schemaLocation with a relative URL?

   My answers are: (1) - yes, and (2) - no.

   Thanks!

   . . . . . . . . . . . . Ken

   --
   UBL/XML/XSLT/XSL-FO training: Vårø, Denmark 2006-10-02/06,11-20/24
   UBL International 2006  2006-11-13/17 http://www.ublconference.com
   World-wide corporate, govt. & user group UBL, XSL, & XML training.
   G. Ken Holman                 mailto:gkholman@CraneSoftwrights.com
   Crane Softwrights Ltd.          http://www.CraneSoftwrights.com/o/
   Box 266, Kars, Ontario CANADA K0A-2E0    +1(613)489-0999 (F:-0995)
   Male Cancer Awareness Aug'05  http://www.CraneSoftwrights.com/o/bc
   Legal business disclaimers:  http://www.CraneSoftwrights.com/legal





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