[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: RE: [ubl-dev] SBS and Restricted Data Types
The challenge would be to determine which contraining facets should be supported for which data types. One could support all constraining facets for all W3C Schema data types, but - as you say - this would require a fair bit of work. Also, unless one repeats the data type that is in the UBL schema that is being subsetted, one would still need to match the constraining facet (though an additional pass, perhaps - depending on implementation) with the data type in the UBL schema to ensure that that constraining facet is valid given the data type (e.g. that there is not an "xsd:maxExclusive" facet specified for an xsd:string data type). One could support a selected set of constraining facets across-the-board for all data types, and then document this as part of SBS - with the notion that implementing a selected set means less costly implementations, which is good for small business. Another aspect to consider is this: All along during this thread, we have been saying that in order to conform to UBL, an implementation of UBL must not reject an instance that the normative schemas would not reject. However, if an implementation restricts - without changing the normative schemas - a string value to, for example, 30 characters, and an instance is received that is 100 characters - which would be considered valid according to the normative schemas - then we are saying that the instance with 100 characters must not be rejected, or the implementation is UBL non-conformant. This definition of conformance may - I believe - therefore need to be relaxed, as how can one have it both ways? (data type restrictions *and* UBL conformance). Just some things to think about... 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: Saturday, May 06, 2006 5:50 AM To: ubl-dev@lists.oasis-open.org Subject: Re: RE: [ubl-dev] SBS and Restricted Data Types Folks Maybe then implementers do need a UBL-standardised (or rather 'specified') supplement to the SBS to provide a set of default datatype restrictions. I guess that's one for the SBSC to consider (it would be a fair bit of work). Other ways exist for this to be provided: such as restrictions of string lengths, etc in the ATG2 datatype schemas or UBL provision and appropriate use of qualified datatypes with such restrictions. These seem unlikely to me. Without something though, it seems implementers might have to support as many tight schemas as they have trading partners - small businesses that is (those who don't have a body acting to create such a tight schema on their behalf). Thanks everyone for bringing this gradually to the fore. All the best Steve >>> "Stephen Green" <stephen_green@bristol-city.gov.uk> 05/05/06 20:57 >>> PM >>> But what if you trade with 2000 others? That's 2000 different deltas. Or a hub - but would the hub want to support up to 1000000 deltas on the customers' behalf? And how about the desire to be able to trade without a lengthy analysis of the deltas? Why not just say "we use ..." and that is it. What about the possibilities of moving towards the situation you have with email or postage where anyone can send to anyone with confidence they can understand and process the message? How long did the public tolerate mobiles which couldn't work with other networks? Some time yes but not indefinitely. IM is going that way, isn't it? All the best Steve >>> "David RR Webber (XML)" <david@drrw.info> 05/05/06 19:53 PM >>> Fulton, What implementers need to know is the delta, or if a delta exists betweeen what they have already and what their partner require. In traditional EDI and XML it is "suck it and see" time. Simply because there is no standard approved way of exposing this in a consistent form. If you have that mechanism then suddenly you alter the equation! It no longer becomes a guessing game - if I send this transaction, will it fail? What LOE will it take to get my system working with theirs? By exposing this all with tools like CAM you dramatically alter the equation. Partners can examine your requirements, and even pre-test samples - before they even cross the bridge of sending transactions to you. Schema cannot do this on its own. In fact it fails pretty much out the gate when it is a large schema - and I believe this is what we are grappling here with SBS - not all these other nuances! Simply put - if I give you the schema - ou still have *no clue* what a valid XML transaction will look like that my system can accept!!! Instead - you have to ask for a sample XML message as well - to know what you are trying to do. And that is iffy too of course. More likely you will need several samplers if its a large schema - based on context and role (that theme again). If this was all like a crossword puzzle - giving someone a schema is like giving them the crossword - with little to no clues!!! So - we're back to the same conclusions - yes - you can significantly improve the adoption metrics here - by implementing the full solution stack that we originally envisioned for ebXML - where the registry provides a pivotal part, along with CPA, context, role, and templates of transactions (aka SBS) so that partners can quickly align with known patterns (CAM templates) based on knowing their context and role. If they have a BPSS available - then they can find that even faster! DW -------- Original Message -------- Subject: RE: [ubl-dev] SBS and Restricted Data Types From: Fulton Wilcox <fulton.wilcox@coltsnecksolutions.com> Date: Fri, May 05, 2006 1:22 pm To: ubl-dv@lists.oasis-open.org Cc: 'Chiusano Joseph' <chiusano_joseph@bah.com>, 'Stephen Green' <stephen_green@bristol-city.gov.uk> All: There is an economic equilibrium between the costs of working within a standard versus the cost of accommodating diversity. If implementing standards become more convoluted, the equilibrium shifts in favor of doing n-way direct translations. Therefore, what Dave described as "the one way is the true way" and "pure UBL" has little to do with truth and a lot to do with minimizing cost of adoption. If the number of particularities increases, the economic equilibrium flips in favor of "pure particularity." Probably any given particularity along the lines of Joe's original message (see below) is unlikely to trigger a shift in the economic equilibrium cited above. However, the accmulation of particularities and embellishments can have that effect. A further issue is that the "cost causers" who impose particularity often are not the "cost payers." For example, the hub in a hub and spoke trading relationship may impose particularities on what could easily be a "pure" UBL trading relationship. Of course, in response many prospective "spokes" exhibit great agility in avoiding or delaying adoption. Everyone involved in UBL has both a standards hat and one or more "particularity" hats. In the interest of the standard, there needs to be a healthy level of impedance to bringing particularity inside the standard. Fulton Wilcox Colts Neck Solutions LLC -----Original Message----- From: Chiusano Joseph [mailto:chiusano_joseph@bah.com] Sent: Tuesday, May 02, 2006 4:35 PM To: ubl-dev@lists.oasis-open.org Subject: [ubl-dev] SBS and Restricted Data Types Please pardon me if this question has been asked before on this list (my searches indicated the contrary): In terms of the SBS, what is the best way (if any) to restrict data types of a UBL schema for an specific implementation? Whether it is a 1.0 or 2.0 schema does no matter for purposes of this question (at least I don't believe so). For example, what if one had a need to define an xsd:minOccurs or xsd:maxOccurs facet for an xsd:string data type, for their own implementation? Thanks, Joe Joseph Chiusano Associate Booz Allen Hamilton --------------------------------------------------------------------- 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/maillist/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/ --------------------------------------------------------------------- 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]