MHonArc v2.5.0b2 -->
ubl-ndrsc message
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]
Subject: NDR rule on namespace's version precedence over explicit version attribute's value
>>It was agreed yesterday
>>by a well attended NDR meeting that there was sufficient reason
>>in this to make it a MUST for UBL (it was nearly a MAY but that
>>left room for inconsistency and uncertainty about use) on the
>>proviso (from Eduardo) that the namespace was still acknowledged
>>(perhaps for historic reasons - i.e. respect to previous discussions)
>>as the first normative mechanism....
Using namespace holders to record version isn't really the
proper way to start off. Namespace values are dependent on
version, not the other way around. In other words, given an
arbitrary namespace value (e.g. XSD's value), we cannot tell
what is the version number. But the other way around, given
a version, we *can* construct (with other input variables)
the actual namespace value. In current UBL's namespace
construction, it so happens that delimiters were amply used
to separate the positional holders so that one could backward
derive the version value. Processing-wise, it does appear
like EDI-sort of processing to fish for the version value
in a colon-delimited string message.
I don't really like the idea of obtaining a version from
namespace holders whose values themselves are dependent on
version.
If special schema processors are able to pick out version
value from namespace (call this VER1), AND then compare
with the version value from the <xsd:schema version> attribute
(call this VER2), and finds that VER1 not equal to VER2,
all that can be safely concluded is that the schema is
not self-consistent. One cannot say that VER1 is "more
accurate" than VER2. One cannot say that VER1 has higher
precedence because VER1 and VER2 do not have any ordering
relation. The schema processor should stop using that
schema and possibly flag an error to end-user.
It is not a good idea to encourage application-defined
defaults to handle such inconsistencies.
The NDR rule pertaining to this should therefore be
to state that schema validators and applications
MUST NOT continue further processing if VER1 <> VER2.
Best Regards,
Chin Chee-Kai
SoftML
Tel: +65-6820-2979
Fax: +65-6743-7875
Email: cheekai@SoftML.Net
http://SoftML.Net/
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]