Including code list schemas in the UBL package

["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