Title: Re: [ubl] Discussion of substitution groups
If I were engaging in a trading
partner
agreement and was agreeing that UBL
2.0
be used. I would hardly want that to
leave
things open to any minor change of
content
2.1, 2.2, 2.3, even 2.99! I would want to
limit
things to say 2.2, 2.0 and maybe 2.1. I
would
want to specifiy this with the
namespace(s)
(perhaps using ebBP, though not
necessarily,
depending on the abilities of trading
partners).
A. I would want 2.0 to mean 2.0 and not
2.*
B. I would want to be able to agree to
use 2.3
(perhaps excluding
2.0 and 2.1 because
they don't include
things I need)
C. I would want to do the above with
namespaces
D. I would want to be able to check the
above
in any particular
instance with the namespace
of that
instance
E. Sometimes I would be unhappy to have
to
cater for 2.4 by
changing the agreement
and extending my
software BUT on the whole
I would prefer that
to not having A to E above
satisfied (e.g. not
knowing whether I'm getting
2.8 which I
don't know about except that it
is in some vague way
'compatible' with 2.0)
F. If I agree to use 2.4, I would be
wary that 2.5
might extend 2.3 and
so be backwards
compatible with 2.0
but not with 2.4
Again, I could go on...
This seems a realistic use case to me. Am I
missing
something?
I agree that there is the concept that you can
ignore
what you don't understand in XML but I can't
ignore the fact that the supply chain
and business
management chain of command might not
understand
or agree with this concept. Fixing the contract to
a
particular, uniquely defined schema or closed
group
(not open ended) of schemas seems to
allay
their fears most satisfactorily.
All the best
Steve
----- Original Message -----
From:
Stephen Green
To:
Sent: Wednesday, July 20, 2005 3:25
PM
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 !!
:-)
