i take your point Jon.
my reaction to this is somewhat akin to yours about list containership.
my experience makes me nervous about this idea, even though it sounds
sensible.
In EDI syntaxes, X12 has similiar data types to XSD, such as ID
(identifier), DT (date), TM(Time), R (percent), etc. it is interesting
to note that when EDIFACT came out it reduced these to three data types
(alphabetic, numeric and alpha-numeric). even so, i have lost count of
the times applications needed to use numeric digits in elements defined
as alphabetic or needed spaces in numerically-defined elements.
i am not advocating we discourage schema validation of data types. i
just wondered if this was best left to the contexts of implementation
and should be defined by extension to the 'vanilla' UBL types if the
customer wants it.
finally, whichever way we go, we should be consistent - we utilise the
precision of XSD datatypes and their derivations (such as dateTime and
token) or we don't. at present we appear to be making arbitary decisions.
wrote:
>| what is the problem with making code and identifier (and every
>| other data type) as 'string'? what are we trying to gain by
>| enforcing patterns in the data?
>
>Basically the same things you get by specifying a schema in the
>first place.
>
>1. The offloading of as much constraint checking as you can onto
> the client in order to minimize the number of returned messages
> from the recipient. This becomes especially important when
> trying to get away from the need for 24x7 connectivity, as in
> the current RosettaNet Appliance effort.
>
>2. The ability of generic schema-aware XML editors to become
> self-configuring data input interfaces.
>
>Jon
>
>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-lcsc/members/leave_workgroup.php.
>
>
>
--
regards
tim mcgrath
phone: +618 93352228
postal: po box 1289 fremantle western australia 6160
