At 2006-07-10 12:08 -0600, 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嶧l, 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:
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
