[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [ubl-dev] Datatype Methodology RE: [ubl-dev] SBS and Restricted Data Types
Chin, One other way of looking at this is that business people especially need to be able to inspect the proposed interchange and quickly see the deltas from the usual. The usual is the default way of handling information - dates, strings, etc. The delta is when limits or checks need to be applied or changes to the model apply (repeatable, optional). In CAM we've taken the declarative approach - so it does make it obvious where and when such deltas exist. The vision has always been that ultimately agent software can actually compare such templates and provide the business analyst with the deltas. E.g. since XPath expressions are used to denote where to apply those deltas - you can easily extract out two or more lists of predicates - one from each template - and then sort by XPath reference and compare... Another tool here is <include> statements. Where a template fragment is created that handles default processing of common blocks of XML content (address is an obvious one). Being able to create sub-components templates - breaking the overall processing down into smaller more manageable chunks is another notion that helps to implement concepts such as SBS. DW -------- Original Message -------- Subject: Re: [ubl-dev] Datatype Methodology RE: [ubl-dev] SBS and Restricted Data Types From: Chin Chee-Kai <cheekai@softml.net> Date: Tue, May 09, 2006 12:22 am To: UBL-Dev <ubl-dev@lists.oasis-open.org> (cc to Ken removed as I believe Ken is on ubl-dev list, cc to ubl list removed as I believe I can't post to it) Ken, I'll like to add to Stephen's thoughts about string length limitations more from the customisation perspective than commenting on your code list methodology. While I agree with you that unlimiting the lengths and bounds of string type (and perhaps to enumerated and other simple types like integer) is easier conceptually for (business) users to deal with, in real life, it is not so much that users don't want fixed lengths but they don't really bother to nor sometimes know about how to specify fixed lengths. Real life (RL) invoices don't come with infinite pages. RL line items don't go indefinitely to the right. RL quantities, no matter how large, are finite. RL values, may it be thousands, millions, billions, trillions, are still finite numerals. What is needed is not something like EDI record style as what you mentioned, a single, standardised fixed-length use-or-else-drop-it bounds on everybody. Making it a one-size-fits-all standard probably will result in fitting nobody. Modern day machines are fast enough with large memory, so whether there is or isn't boundary limits on schemas won't help nor create resistance to programmers too much. In some sense, unlimited cases (such as infinite string lengths in schema) are even easier to program (as you know), because the lengths of incoming instances need not be checked. What I think is needed, and subject to business experts further criticisms and assessments, would be a standardised way of customisation, and in the case of strings, a standardised way of fixing the constant lengths, patterns, bounds for string-represented integers, etc, so that those fixed constants can help the application or business user in context to filter out irrelevant instance inputs (relative to its local context). So Stephen's suggestion for a UBL customisation, and I would perhaps hope it to be a specification rather than just a documentary methodology, is both timely and needed. While I also think this needs to co-exist consistently with code list methodology, it need not start from code list methodology. (These are just my views and I suppose you may have yours very differently, and I respect the points you've made or will make. But I just hope to convey a, perhaps small, commonality in thinking that could be useful to creating a customisation specification for UBL). Thanks. Best Regards, Chin Chee-Kai SoftML Tel: +65-6820-2979 Fax: +65-6820-2979 Email: cheekai@SoftML.Net http://SoftML.Net/ On Mon, 8 May 2006, G. Ken Holman wrote: >>At 2006-05-08 12:10 -0600, stephen.green@systml.co.uk wrote: >>..... >> >>>The codelist methodology allows for this. We seem to need a >>>way to apply such criteria to datatypes other than codes. >> >>Again I'm interested to know why ... I know what you are asking, but >>not the justification to limit some business users' needs for, say, >>long description fields. >> >>>In some cases >>>it might be that an instance is invalid with Text types having an over >>>long string value. In other cases it might be that they aren't invalid but >>>an non-fatal exception is raised (the latter being more along the lines >>>of the SBS subsetting methodology). >> >>But is this being done because of poor program design that >>arbitrarily limits the string values rather than accommodating >>business needs for long strings? I thought I got away from string >>limits when I got away from programming in COBOL and RPG II ... those >>were the last programming languages I used where records were mapped >>to fixed-length fields. >> >>I think fixed-length limitations are anathema to *document-oriented* >>processing and is too *record-oriented*. >> >>>Maybe the latter could be called 'UBL subsetting' and the former 'UBL >>>profiling' (the codelist methodology seeming to suggest 'UBL profiling' >>>for codelists). >> >>... >> >>But, again, string limitations are just not (to me) >>document-oriented. If a business user needs to express their line >>item description in 1001 characters, then using 1000 characters must >>not have been appropriate. >> >>. . . . . . . . . . . . . Ken >> >>-- >>Registration open for XSLT/XSL-FO training: Wash.,DC 2006-06-12/16 >>Also for XSLT/XSL-FO training: Minneapolis, MN 2006-07-31/08-04 >>Also for XML/XSLT/XSL-FO training:Birmingham,England 2006-05-22/25 >>Also for XSLT/XSL-FO training: Copenhagen,Denmark 2006-05-08/11 >>World-wide on-site corporate, govt. & user group XML/XSL training. >>G. Ken Holman mailto:gkholman@CraneSoftwrights.com >>Crane Softwrights Ltd. http://www.CraneSoftwrights.com/o/ >>Box 266, Kars, Ontario CANADA K0A-2E0 +1(613)489-0999 (F:-0995) >>Male Cancer Awareness Aug'05 http://www.CraneSoftwrights.com/o/bc >>Legal business disclaimers: http://www.CraneSoftwrights.com/legal >> >> >>--------------------------------------------------------------------- >>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]