Re: [ubl] Version number in file names

["G. Ken Holman" <gkholman@CraneSoftwrights.com>]

At 2006-07-10 12:08 -0600, stephen.green@systml.co.uk wrote:
>The advantage in having no difference in the filename is that
>there is then no need to change the schemaLocation in the instance
>if a new minor version becomes active.

Oh!  Of course ... in the instance it would be a problem.  Thank you Stephen.

I'm anticipating that minor version schemata will 
be delivered in toto with self-referential 
integrity, thus I wasn't anticipating any 
problems that a suite of schema files would be 
able to validate an arbitrary instance.

>Otherwise there would be
>unnecessary incompatibility for minor versions in instances which
>are otherwise agnostic about which minor version they use (where
>backwards compatibility is concerned). Otherwise there is little
>to be gained from keeping the same namespace for minor versions
>(and using the UBLVersionID element) when schemaLocation is used
>in instances, as is the usual case with UBl instances it seems.

How could we measure this?

I ask because I believe there is tremendous gain 
in keeping the same namespace for minor versions 
of existing information items (and I've suggested 
using a new minor namespace for new information 
items introduced in minor versions), but I've 
always felt strongly *from a file management 
perspective* that the artefacts themselves would have unique file names.

A number of XML cognoscenti firmly believe it was 
wrong in XML document type declarations to have 
to identify the model of constraints against 
which a document is always tested.  Constraints 
should be tested dynamically based on situational 
requirements.  Indeed using RELAX-NG one is 
*obliged* to reference the set of constraints 
from outside of the document and one cannot embed 
in a document a reference to said constraints.

I think xsi:schemaLocation should be considered 
harmful and that good practice prohibits its use 
... but I acknowledge that cannot prevent it from being used.

I would like to propose that we explicitly break 
the compatibility of xsi:schemaLocation in favour 
of file management and that we recommend UBL 
instances not use xsi:schemaLocation ... I even 
suspect we'll have validation issues with our 
schema expressions when xsi:schemaLocation is 
used in a document, but right now I don't have 
the time to test this (I want to answer your post 
immediately as I think this is an important discussion).

Consider that Joe Public uses xsi:schemaLocation 
to point to his local version of the schema and 
he sends the instance to Jane Citizen who tries 
to work with the instance in her 
environment.  The instance is "broken" from her 
perspective as the instance points to a 
non-existent schema in her environment.  We are 
trying to build an international interoperable 
environment, thus I think we are justified in 
debating the prohibition of xsi:schemaLocation.

At the least I'd like us to consider forcing file name distinction.

I vote for "globally correct" over "localized convenience".

Thank you, Stephen, for bringing this important issue to light.

. . . . . . . . . Ken

--
Registration open for UBL training:    Montréal, Canada 2006-08-07
Also for XSL-FO/XSLT training:    Minneapolis, MN 2006-07-31/08-04
Also for UBL/XML/XSLT/XSL-FO training: Varo,Denmark 06-09-25/10-06
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