[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [ubl-ndrsc] range of valid values for cc types
Comment below Anne Hendry wrote: > http://www.w3.org/TR/xmlschema-2/#decimal (excerpt below) specifies > decimal quite specifically in terms of numbers of digits and leading > +/-, etc, and since both positive and negative values are intrinsic to > the data type, unless we've restricted it somehow already (which I > couldn't find) I don't think it would require any special handling: > ... > > decimal has a lexical representation consisting of a finite-length > sequence of decimal digits (#x30-#x39) separated by a period as a > decimal indicator. If ·totalDigits· > <http://www.w3.org/TR/xmlschema-2/#dt-totalDigits> is specified, the > number of digits must be less than or equal to ·totalDigits· > <http://www.w3.org/TR/xmlschema-2/#dt-totalDigits>. If ·fractionDigits· > <http://www.w3.org/TR/xmlschema-2/#dt-fractionDigits> is specified, the > number of digits following the decimal point must be less than or equal > to the ·fractionDigits· > <http://www.w3.org/TR/xmlschema-2/#dt-fractionDigits>. An optional > leading sign is allowed. If the sign is omitted, "+" is assumed. Leading > and trailing zeroes are optional. If the fractional part is zero, the > period and following zero(es) can be omitted. For example: -1.23, > 12678967.543233, +100000.00, 210. > > ... > > Looking at the ccts and our cct xsd from beta, they're just a > pass-through of the above (and a few other xs specification details). > But you might want to read through this part of the schema spec (decimal > and datetime), if you haven't already. > > However it sounds from your question that you're also asking about > formatting (when/how to use the period as a thousands separator, etc)? > Wouldn't this be more a contextualized (locale-specific) presentation > issue more than a datatype issue? Your suggestion to associate it with > each type of currency I think is how it's currently done in most > application localisation processes. The numeric display details are > specified as part of the overall locale which would also include > language, currency, date/time zone, character type (single or > multi-byte), collation sequencing, etc. At least this is how I'm used > to it being handled. It's a localization issue, and is often handled by > os level translation routines. Actually in this case it should be handled not by the OS but by the style-sheet used to extract data from the instance and present it to the user. It would be disastrous to either (a) leave it to the OS or (b) have one formatting specification within the instance that would override all localization considerations. > > -A > > Stephen Green wrote: > >> Hi >> >> Please may I add to Anne's question the matter of: >> >> Would there be any need to specify *how* (leading >> sign, trailing sign, etc) a negative amount is >> specified as a separate BIE to ensure correct >> interpretation of the negative aspect? Is the >> expression of negativity controlled enough so as to >> be clear and unambiguous? >> >> This is similar to >> another issue - Do we need precision BIE(s) to >> allow unambiguous expression of a) decimals >> (separator = . or , or ...etc) b) 1000s etc separators >> - either adding separate BIE(s) for decimal places >> (might have to instead find a way to associate this >> kind of data with each amount or currency), etc. >> >> (Behind this is the wide range of uses worldwide of >> different ways to express decimals, thousands or >> tens of thousands and positive/negative sign.) >> >> Perhaps this value metadata should be attributes of an >> amount (particularly decimal places and/or separator >> and pre-decimal number of digits and/or thousand (etc) >> separator and ,as my original question asks, whether >> negative or positive and/or leading or trailing sign (etc)) >> >> then >> >> Is it catered for by either >> a) something in the CCT Spec >> to limit how the above are expressed or indicated and/or >> b) something in the CCT supplementary components or >> xsd base type? >> >> If not, can we add supplementary components for these of >> our own? >> Or should we be thinking of adding BIEs? >> Or should we just leave it for implementers? (???) >> >> I guess it applies too to cct:Quantity and cct:Measure as >> well as to cct:Amount. >> >> Thanks >> >> Steve >> ----- Original Message ----- >> From: "Anne Hendry" <anne.hendry@sun.com> >> To: <ubl-ndrsc@lists.oasis-open.org> >> Sent: Tuesday, February 03, 2004 7:08 AM >> Subject: [ubl-ndrsc] range of valid values for cc types >> >> >> >> >>> Hi, >>> >>> In a recent Libarary Content meeting there was a question as to whether >>> negative values could be valid values for some entities, as in the case >>> of an adjustment amount. In looking at >>> UBL-CoreComponentTypes-1.0-beta.xsd and >>> UBL-CoreComponentParameters-1.0-beta.xsd (from UBL 1.0 Beta), I noticed >>> these types defined: >>> >>> cct:AmountType based on xsd:decimal >>> cct::DateTimeType based on xsd:dateTime >>> cct:IdentifierType based on xsd:decimal >>> cct:MeasureType based on xsd:decimal >>> cct:NumericType baed on xsd:decimal >>> cct:QuantityType based on xsd:decimal >>> >>> rt:DateTimeType based on cct:DateTimeType >>> rt:DateType based on xsd:date >>> rt:TimeType based on xsd:time >>> rt:MeasureType based on cctMeasureType >>> rtNumericType based on cct:NumericType >>> rt:ValueType based on cct:NumericType >>> rt:RateType based on cct:NumericType >>> rt:QuantityType based on cct:QuantityType >>> >>> Since all the base types used by cct noted above are xs primitive types >>> that allow negative values, and I can't see anywhere in either of the >>> above files where there are any restrictions in terms of >>> positive/negative value ranges (eg. no use of derived types such as >>> PositiveInteger, nonNegativeInteger, unsgined*, etc), is it safe to >>> assume the range of valid values for UBL entities based on these CC >>> types includes the full range of values as allowed by the w3c schema >>> primitive types on which they're based? >>> >>> >>> Thanks, >>> Anne >>> >>> >>> To unsubscribe from this mailing list (and be removed from the roster of >>> >> >> the OASIS TC), go to >> http://www.oasis-open.org/apps/org/workgroup/ubl-ndrsc/members/leave_workgro >> >> up.php. >> >> >>> >> >> >> >> To unsubscribe from this mailing list (and be removed from the roster >> of the OASIS TC), go to >> http://www.oasis-open.org/apps/org/workgroup/ubl-ndrsc/members/leave_workgroup.php. >> >> >> >> > > > > To unsubscribe from this mailing list (and be removed from the roster of > the OASIS TC), go to > http://www.oasis-open.org/apps/org/workgroup/ubl-ndrsc/members/leave_workgroup.php. > > -- Eduardo Gutentag | e-mail: eduardo.gutentag@Sun.COM Web Technologies and Standards | Phone: +1 510 550 4616 x31442 Sun Microsystems Inc. | W3C AC Rep / OASIS BoD
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]