[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
<Quote> After all, should my application have to be able to support musical notation or hieroglyphics in a product description? </Quote> If there is a way for us to enable UBL-conformant applications to sing line item descriptions to users, now that would be cool (not to mention supporting Sanskrit*;) Joe *I once took an undergraduate course in conversational Sanskrit Kind Regards, 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: Tuesday, May 09, 2006 5:56 AM To: ubl-dev@lists.oasis-open.org; ubl@lists.oasis-open.org 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 > U+Unicode 206C .. U+206D Activate/Inhibit Arabic form shaping > U+Deprecated in Unicode 206E .. U+206F Activate/Inhibit National digit > U+shapes Deprecated in Unicode > > U+FFF9 .. U+FFFB Interlinear annotation characters Use ruby markup > U+[Ruby] FEFF Byte order mark / ZWNBSP Use only as byte order mark. > U+Use U+2060 Word > Joiner instead of using U+FEFF as ZWNBSP > U+FFFC Object replacement character Use markup 1D173..U+1D173A Scoping > U+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/ > > --------------------------------------------------------------------- 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]