[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [ubl-dev] SBS and Restricted Data Types
I want to make sure I don't misunderstand here - please clarify: <Quote> I totally agree. But then those supply chains should provide such solutions, say as customisations, rather than UBL (which doesn't have a separate body for each industry but relies, I believe, on those industries to do such things). </Quote> By "rather than UBL", did you mean to say that those supply chains should *not* use UBL at all because they have a need for data type restrictions? Or did you mean customizations of UBL? <Quote> I postulate that basing supply-chain-specific subsets on the SBS might achieve this by encouraging software providers to support the SBS, if there is only the minimal departure from the SBS that is necessary and the SBS can work within those limits unchanged too. </Quote> So by "if there is only the minimal departure from the SBS that is necessary" I think you are saying that if an initiative (such as a supply chain) had a need to enforce restrictions on data types (such as string length), then the SBS is not useful for them. Is my understanding correct? Thanks, 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 [mailto:stephen_green@bristol-city.gov.uk] Sent: Thursday, May 04, 2006 11:51 AM To: Chiusano Joseph; ubl-dev@lists.oasis-open.org Subject: RE: [ubl-dev] SBS and Restricted Data Types I totally agree. But then those supply chains should provide such solutions, say as customisations, rather than UBL (which doesn't have a separate body for each industry but relies, I believe, on those industries to do such things). So I don't disagree that more granular subsets might be defined for individual supply chains. I believe there is a civil duty to try to make things work, though, for not just large to small business trade in the supply chain (B2b) but also for small to small business trade around the edges of the chain (b2b). I postulate that basing supply-chain-specific subsets on the SBS might achieve this by encouraging software providers to support the SBS, if there is only the minimal departure from the SBS that is necessary and the SBS can work within those limits unchanged too. All the best Steve >>> "Chiusano Joseph" <chiusano_joseph@bah.com> 04/05/06 16:31:30 >>> Steve, Thanks for your response below on interoperabilty and data type restriction. What I think your response discounted was the notion of trading partners interoperating per a "contract" (meaning technical contract here). Saying that "What seems reasonable if it fits your own requirements looks like an interoperability problem to those whose requirements are different." is certainly true of trading partners that are not involved in the same initiative (e.g. a supply chain), but - IMHO - not true of those that are. After all, the same could be said for - for instance - element names (thinking of your example below of "color" vs. "colour"). If interoperability can be achieved with all trading partners involved in a particular initiative for element names by providing them with the same XML schema, why can't it be done for data type restrictions as well? Sure, you may have a trading partner that uses a different vocabulary and therefore they have an element named "colour" - but there are, of course, ways to handle that (e.g. a semantic mediation service that gracefully and transparently handles the translation of element names). The same would apply for data type restrictions - if there were some overriding, unavoidable reason that a trading partner could not honor a length for a description of (say) 30 characters, and they instead sent you 100, then there needs to be requirements for handling this situation (e.g. is it ok to truncate the characters beyond the 30th?). What has happened to the notion of contract-based interoperabilty, where trading partners adhered to a technical contract to the greatest degree feasible and possible? Why leave data type restrictions (such as string length) out in the cold? I really don't understand what the issue is here (please note that that is not a criticism of your perspective). So with all due respect, and for what it may be worth, I completely differ with your views on interoperability as expressed below. That is not to say in any way that they are incorrect - I just have a very different perspective on interoperability, and the possibilities that can be realized. Please correct my thinking if needed - I want to be told I am wrong if you or anyone else believes I am. Thanks, 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 3:03 PM To: ubl-dev@lists.oasis-open.org Cc: ubl-sbsc@lists.oasis-open.org Subject: RE: [ubl-dev] SBS and Restricted Data Types 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 --------------------------------------------------------------------- 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/ --------------------------------------------------------------------- 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/
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]