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

 


Help: OASIS Mailing Lists Help | MarkMail Help

ubl message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: SV: [ubl] Re: [ubl-dev] Datatype Methodology RE: [ubl-dev] SBS and Restricted Data Types


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 



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]