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

[stephen.green@systml.co.uk]

Yes. This has implications on state and business process in that if
one party thinks the XML is valid or invalid then the other party would
have to have confidence that this was what it too called valid/invalid or
an exception to say it was invalid would not be reliable. That's
just my opinion but I'd guess it's the main reason XSD is used by
those writing document standards to define those standards. Else,
where is the dividing line between what a standards group provides
and the implemenation software (though there are of course exceptions)?
Both sides agreeing a business process and business conditions have
to have confidence that they are signing from the same songsheet with
the same meanings of terms, that including 'valid' and 'invalid'. So
an exception saying 'invalid instance' has to surely mean the same
(within acceptable tolerance) to all parties in the transaction.

Steve



Quoting Chiusano Joseph <chiusano_joseph@bah.com>:

> <Quote>
> A note to all: it seems prudent to only work within the confines of what
> is so readily determinable as to allow accurate state synchronisation
> across transactions. This would be limited in each situation by software
> capabilities on both sides of the transaction For standards efforts
> and/or open trading scenarios a sensible common denominator (perhaps
> lowest common denominator as aimed at with the SBS) has to be assumed.
> This suggests use of Schematron and XSD schema as a means to guauge what
> is feasible.
> </Quote>
>
> Steve,
>
> Your reference to "state synchronization" above threw me a bit because
> it's fundamentally a process-oriented concept (thinking of WS-BPEL, W3C
> WS-CDL, etc.). I want to make sure that I don't miss a point that you're
> making - are you perhaps referring to what I would call a "common state
> of validity", where what is considered valid/invalid by a sender is also
> considered so by a receipient, for each and every "piece" of information
> transmitted?
>
> Joe
>
> Joseph Chiusano
> Associate
> Booz Allen Hamilton
>
> 700 13th St. NW, Suite 1100
> Washington, DC 20005
> O: 202-508-6514
> C: 202-251-0731
> Visit us online@ http://www.boozallen.com
>
> -----Original Message-----
> From: stephen.green@systml.co.uk [mailto:stephen.green@systml.co.uk]
> Sent: Wednesday, May 03, 2006 8:12 AM
> To: ubl-dev@lists.oasis-open.org
> Subject: RE: [ubl-dev] SBS and Restricted Data Types
>
> Ken, sorry not to have read your posting before writing mine on the last
> question.
>
> One other thing though: How would you reckon the feasibility of
> logically validating that a subset which includes pattern restrictions
> of strings is a true strict subset of a schema?
> Is it a step too far for now? If so I'd propose that adding pattern
> restrictions might best be kept to specific agreements or individual
> software implementations rather than including such in a standardisation
> effort such as the SBS.
>
> A note to all: it seems prudent to only work within the confines of what
> is so readily determinable as to allow accurate state synchronisation
> across transactions. This would be limited in each situation by software
> capabilities on both sides of the transaction For standards efforts
> and/or open trading scenarios a sensible common denominator (perhaps
> lowest common denominator as aimed at with the SBS) has to be assumed.
> This suggests use of Schematron and XSD schema as a means to guauge what
> is feasible.
>
> Thanks
>
> Steve
>
>
> ---------------------------------------------------------------------
> This publicly archived list supports open discussion on implementing the
> UBL OASIS Standard. To minimize spam in the archives, you must subscribe
> before posting.
>
> [Un]Subscribe/change address: http://www.oasis-open.org/mlmanage/
> Alternately, using email: list-[un]subscribe@lists.oasis-open.org
> List archives: http://lists.oasis-open.org/archives/ubl-dev/
> Committee homepage: http://www.oasis-open.org/committees/ubl/
> List Guidelines: http://www.oasis-open.org/maillists/guidelines.php
> Join OASIS: http://www.oasis-open.org/join/
>