[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [ubl-dev] Formatting of Identifiers in UBL documents
For example, my government issued business number is formatted "XXXXXX-X". My Canadian tax number is formatted "XXXXX XXXX XX". My US tax number is formatted "XX-XXXXXXX". These are all off of official documents, thus I would expect to encode them in data as registered, opting to display them differently only in formatting if desired (though one would be hard-pressed to present these differently).
Looking at my phone bill, I see 10 digits with no punctuation as the registered phone number. This could be displayed as "XXX-XXX-XXXX" or "(XXX)XXX-XXXX" or some other way. That doesn't include the country code, so I guess there is some ambiguity then when making the number internationalized. But a phone number isn't something that would likely need a normative representation for comparison purposes ... I doubt anyone would need to do a search on phone number.
So I guess I could summarize my thought as the data representation would have to be normative (for comparison reasons) and that the visual representation would be cultural.
. . . . . . . Ken At 2014-04-14 14:57 +0800, Tim McGrath wrote:
I agree with Stephen. There is a general principle here.Formats (of any data element) and other facets are 'presentational' features not part of the structure or semantics of the item. With identifiers we may get confused into thinking they are numbers - but they are just patterns of characters. If those patterns have special characters, spaces, hyphens, etc. then that is the identifier value and is communicated as such.However, if you use formatting techniques to make these values more readable (like people do for entering credit card numbers) - thats not affecting the value of the identifiers and should not be part of a global standard like UBL.UBL only defines structures and semantics ('transactional') models and not presentation features. That means no "XXX-XXX-XXX". That is why the CCTS Data Types avoid specifying formats but provide mechanisms for customized qualified data types to have facets that implementations may use to format elements. Of course with UBL (and any XML) schematron rules and/or stylesheets can be applied to present the formatted data but this is downstream processing and not part of the UBL standard.As Stephen said formats are best seen as a implementation feature for local business rules - specific to a given community of use.On 13/04/2014, at 11:15 PM, Stephen D Green wrote: > Hi Kees > > This would very much be implementation guide material, especially > tax-related information, if there is any business-process sensitive > significance to the Identifier formatting. I would think that in most > cases, since a major use case for UBL is replacement of a paper-based > system with as near as possible an electronic based system as it can > be to the paper-based system, the formatting is insignificant (a > receiving system should be able to format or reformat the ID if > necessary or throw an exception for a human to reformat it if > absolutely necessary). Where necessary to have specific formatting in > the ID in the UBL, that would need to be agreed between parties or > amongst the community. > > I hope this helps > Best regards > > Steve > --- > Stephen D Green > > > On 11 April 2014 14:57, Duvekot, Kees <kduvekot@wehkamp.nl> wrote: >> All, >>>> what is the "standard methode" for showing the way Identifiers (eg: VAT Numbers, IBAN number, Item ID's) should be formatted when they are displayed in a "printed form" (on screen or in PDF/PS/Hardcopy) >> So where is the knowledge maintained how to deal with with "spaces" , dashes or other formatting logic for these identifiers.>>>> Should the identifier in a UBL document already be in formatted form? (so the generating application needs to have this logic) >> Should they be in unformatted form and should that logica be maintained in seperate logic when they are displayed (eg StyleSheets, html formatting etc etc) based on the scheme ID's?>> any other ways? >> >> Regards, >> >> >> Kees Duvekot >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: ubl-dev-unsubscribe@lists.oasis-open.org >> For additional commands, e-mail: ubl-dev-help@lists.oasis-open.org >> > > --------------------------------------------------------------------- > To unsubscribe, e-mail: ubl-dev-unsubscribe@lists.oasis-open.org > For additional commands, e-mail: ubl-dev-help@lists.oasis-open.org > ----------------- Regards Tim McGrath tim.mcgrath@documentengineeringservices.com Fremantle, Western Australia http://www.documentengineeringservices.com --------------------------------------------------------------------- To unsubscribe, e-mail: ubl-dev-unsubscribe@lists.oasis-open.org For additional commands, e-mail: ubl-dev-help@lists.oasis-open.org
-- Public XSLT, XSL-FO, UBL & code list classes: Melbourne, AU May 2014 | Contact us for world-wide XML consulting and instructor-led training | Free 5-hour lecture: http://www.CraneSoftwrights.com/links/udemy.htm | Crane Softwrights Ltd. http://www.CraneSoftwrights.com/u/ | G. Ken Holman mailto:gkholman@CraneSoftwrights.com | Google+ profile: http://plus.google.com/+GKenHolman-Crane/about | Legal business disclaimers: http://www.CraneSoftwrights.com/legal | --- This email is free from viruses and malware because avast! Antivirus protection is active. http://www.avast.com
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]