RE: [ubl-dev] SBS and Restricted Data Types

[stephen.green@systml.co.uk]

Answering whether interoperability might be helped
by further restricting datatypes in a subset like SBS:

What seems reasonable if it fits your own requirements
looks like an interoperability problem to those whose
requirements are different. If to send a paper invoice
one could only use a particular make and color of ink
or use 'color' as a spelling and not 'colour' :-) then
that doesn't solve most people's interop problems - just
some people's.

To put it another way, if I'm writing a standard for how
houses are built on a specific housing estate and say they
can only be built with bricks that might be acceptable.
If I say the same when writing a national law or an
international standard it isn't OK, especially for those
who have for some reason to use bamboo or wood or concrete.

Forgive my analogies but in plain terms one system might
only take zip codes 10 characters long, others might only
use numerics, others might have to cater for a particular
pattern. 'string', in this case is the only interoperable
and universally acceptable option because of the scope
required and to be catered for. The same is the case with
most UBL datatypes and the SBS has a scope which doesn't
in the case of this particular subset change those
requirements. It typically defers choice of datatype to the
full UBL model (unless there is a clear reason not to).

In a differently limited scope one can be more specific about the
requirements and therefore perhaps about the datatypes. If the
SBS were to cater for such scenarios it might need a lot more
work - more than resources permit. At best SBSC might provide
something adaptable to other needs in the methodology. That's
my opinion anyway.

All the best

Steve