Title: Re: [ubl] Discussion of substitution groups
I guess I expect that, with the design you are
articulating, the schema
filename might not have
the minor version as
a mandatory inclusion.
Also, if this same-namespace minor
version
design were adopted, so that software
receives
newer versions obliviously, to take
advantage
of this feature you'd want to call a schema
minor
'upgrade' by the same file name as the
previous
schema. There might not be much point
keeping
the 'space' name (namespace) but changing
the
filename, would there?
The schemaLocation is vague because it
can
be relative so you could make the
schema
minor version distinction by giving the
schemas
the same name but storing them in
different
absolute locations (a sort of external
polymorphism
without the audit trail). The relative location in
the
instance could be such that a different schema
is
pointed to depending on the location of
the
instance or some kind of caching, etc
(which
could change anyway as technology
changes).
That's what I mean by vague.
In short I wouldn't be so happy about
trading
under such an 'standard' architecture.
Nor,
I think, would my auditors or tax
authority!
(I'm not seeking to speak for these but
just
anticipating likely objections later which
could
hinder UBL adoption drastically.) I'd think
there
would be the addition of substantial
ambuiguity
by relying solely on the schemaLocation
and
schema filename rather than the
namespace.
In particular: The following doesn't look too good
-
the trading agreement gives the schema
filename
rather than the namespace (as normative).
??
That's what you get if you defer the
minor
version name to the filename but leave it
out
of the namespace.
All the best
Steve
----- Original Message -----
From:
CRAWFORD, Mark
To:
;
Sent: Wednesday, July 20, 2005 3:39
PM
Subject: Re: [ubl] Discussion of
substitution groups
Since the schema location is versioned, not sure why you keep
referring to it as vague.
Mark R. Crawford
Senior Research Fellow - LMI
XML Lead
W3C Advisory Committee and OASIS Representative,
Vice Chair -
OASIS UBL TC
Vice Chair - UN/CEFACT Applied Technologies Group
Chair -
UN/CEFACT XML Syntax Working Group
Co-Chair ISO TC154 Subcommittee for ISO
15000-5
--
LMI Government Consulting
2000 Corporate Ridge
McLean,
VA 22102-7805
703.917.7177 Phone
703.655.4810 Wireless
The
opportunity to make a difference has never been
greater
www.lmi.org
-----Original Message-----
From: Stephen
Green <>
To:
<>
Sent: Wed Jul 20
10:25:03 2005
Subject: Re: [ubl] Discussion of substitution
groups
Of course, the version attribute of the schema
is useless in
this regard, as would be annotations
for CCTS which, too, are only held in
the schema.
Neither can be referenced in the instance, only,
correct me
if I'm wrong, the namespace and the
schemaLocation (which could be vague)
can
appear in the instance to identify a schema or
an identifier within
the schema in a well-known,
standard way. Creating a BIE so that
something
else in instances does the same job, or worse, putting
that
data into another document separate from the
instance, IMHO just moves the
version data to somewhere
far less well-known, far less
established.
Besides, I though it was intended that UBL
supports
uses which are independant of ebXML, so forcing
use of
CCTS-aware registries seems contrary to that
(if that is the alternative
being offered to XSD derivation).
Likewise, adopting approaches as
alternatives to
straightforward (though complex) uses of XSD
seems
contrary to another NDR first principle of
UBL.
Steve
I
doubt even more whether
the
version attribute could do the job. I
doubt
more still that it could
be done with a UBL BIE
for
version.
11. I hope nobody suggests that the
version
annotation in the schema
be used !!
:-)
