ubl — archive

[Ken Holman]

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