Re: [ubl-ndrsc] NDR rule on namespace's version precedenceover explicit version attribute's value

["Stephen Green" <stephen_green@bristol-city.gov.uk>]

It does seem to make sense to me that the version number is easier to get automatically from a standard version attribute of an unknown schema root element than a version element of an unfamiliar namespace. 

Steve

>>> Chin Chee-Kai <cheekai@softml.net> 02/10/03 10:29:14 >>>
>>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/ 



To unsubscribe from this mailing list (and be removed from the roster of the OASIS TC), go to http://www.oasis-open.org/apps/org/workgroup/ubl-ndrsc/members/leave_workgroup.php.