OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

ubl message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

Subject: Re: [ubl] Discussion of substitution groups

> namespace versions are only indications of the specific vocabulary set I
> am drawing from.  

That's the point I object to - this sort of vagueness may be OK
for something like HTML (where browsers can just happily
ignore the fact that, probably, no namespace is given or
ignore the namespace, perhaps, even if it is given). In the case
of legal business documents where millions may ride on the
exact business semantics and content there could be serious
abuse of not stating a namespace or, equally, of the namespace
alone not pinning down the exact business semantics and content.

This seems to me to be even more important than whether xsd:any
can lead to abuse. Allowing any number of so-called compatible
future minor versions to a schema without a change of namespace
seems to me like one gigantic 'any' but in the root rather than a leaf.

This is excacerbated if we don't restrict minor versions to those
allowed by xsd:derivation through xsd:substitutionGroup. It means
there is no way to ascertain that a later minor version schema is
compatible (which has then become an arbitrary concept) with
the version(s) folk are currently using.

So in short, I believe that, provided a suitable method exists and
is adequately supported and practical, if the minor versions can
be forced to be backwards compatible they should be in UBL and
if the namespace itself should include both the major AND the
minor version information so that trading agreements can easily
limit adoption to one precise major OR minor version (or exact
set of versions). It can then all be ascertained PERPETUALLY
in the instance itself. (Using the schemaLocation to do this would
be open to change unless persistent urls are always used and the
schema the url points is never changed, something that seems less
than likely in one or the other case. Keeping the existing NDR rule
for minor version namespaces seems more likely to be reliable
from auditors' and lawyers points of view, a benefit of 
standardisation one would hope. Never changing schemas in specific
persistent locations for both major and minor versions would support

All the best


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]