[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [ubl-dev] SV: [ubl] Re: [ubl-dev] Datatype Methodology RE:[ubl-dev] SBS and Restricted Data Types
Bryan, All, This raises and interesting point. There is surely an important need to specify in a trading agreement the character set to be used in the documents. I wonder whether even CAM has this :-) After all, should my application have to be able to support musical notation or hieroglyphics in a product description? Maybe there should be a way to specify a subset of a character set too (especially if it is Unicode we are talking about). I bet many have had problems when a character decodes to two characters in certain systems (e.g. the GBP sign £): not good for translation to fixed width and/or EDI. All the best Steve Quoting Bryan Rasmussen <BRS@itst.dk>: > I agree with not setting string length restrictions, I think it would be nice > to have string length minimums or constraints to require some content in an > element if the element is required, but it's not a big thing for me. > > Another thing though would be restricting characters that are not needed, as > per the recommendations in http://www.w3.org/TR/unicode-xml/#Suitable > > I think what should be restricted is (from document): > > U+202A .. U+202E BIDI embedding controls > (LRE, RLE, LRO, RLO, PDF) Strongly discouraged in [HTML 4.0] > U+206A .. U+206B Activate/Inhibit Symmetric swapping Deprecated in Unicode > U+206C .. U+206D Activate/Inhibit Arabic form shaping Deprecated in Unicode > U+206E .. U+206F Activate/Inhibit National digit shapes Deprecated in Unicode > > U+FFF9 .. U+FFFB Interlinear annotation characters Use ruby markup [Ruby] > U+FEFF Byte order mark / ZWNBSP Use only as byte order mark. Use U+2060 Word > Joiner instead of using U+FEFF as ZWNBSP > U+FFFC Object replacement character Use markup > U+1D173..U+1D173A Scoping for Musical Notation Use an appropriate markup > language > U+E0000 .. U+E007F Language Tag codepoints > > I don't want to restrict the use of line feeds etc. as is recommended in the > aforementioned document. > > Cheers, > Bryan Rasmussen > > > > -----Oprindelig meddelelse----- > Fra: G. Ken Holman [mailto:gkholman@CraneSoftwrights.com] > Sendt: 8. maj 2006 20:45 > Til: ubl-dev@lists.oasis-open.org; ubl@lists.oasis-open.org > Emne: [ubl] Re: [ubl-dev] Datatype Methodology RE: [ubl-dev] SBS and > Restricted Data Types > > > At 2006-05-08 12:10 -0600, stephen.green@systml.co.uk wrote: >> Following the conversations prompted by Joseph Chiusano I've an idea >> UBL might need, besides its Codelist Methodology, a general methodology >> for at least restricting datatypes and maybe extending them in some >> cases. > > I'm not yet convinced, but I don't want to stop the debate and I may > yet be swayed. > >> I was thinking that it is possible with UBL to extend and restrict >> enumerated codelists without it being called customisation. Yet to do >> this with other datatypes it might be necessary at the present to call >> it customisation. How about in future adding to the Codelist Methodology >> a way to do the same or similar (as one can for codelists) with other >> datatypes. > > But why is it being done in the first place? It seems to me to be > accommodating vendors and not users, creating an artificial limit to > accommodate programs rather than letting business use what they need > and having the program accommodate the users. > >> A trading agreement which limits the currencies used to just USD might >> be such that a document with other currencies included isn't regarded >> as valid. > > From a business perspective, yes. > >> 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). > > Why not just "business rules" or "application rules"? > > Though I'm still not convinced they are justified. If a business > user finds the XML vocabulary suits their needs but the application > software doesn't, they could look for application software that > does. If they, then, decide that they cannot for whatever reason > change the application, then they have a business rule for limiting > it, say, as a non-fatal error message. > > Jon has already requested the supplementing of code list constraint > checking with trading partner business rules in a single Schematron > pass, so I'm building into the 0.5 methodology a way to include > arbitrary Schematron rules in addition to synthesized Schematron > rules so that trading partners can exchange and point to their own > supplemental Schematron expressions that have constraints to be > included with, but considered higher priority, than the synthesized > Schematron rules. BTW, I haven't figured the most elegant way to do > this yet, but I'm working on it. > > 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 > > > --------------------------------------------------------------------- > To unsubscribe from this mail list, you must leave the OASIS TC that > generates this mail. You may a link to this group and all your TCs in OASIS > at: > https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php > > > --------------------------------------------------------------------- > 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]