OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

ubl-dev message

[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]