[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [ubl-dev] Formatting of Identifiers in UBL documents
I like Ken's reasoning on this.
How would implementation guides represent these normative
representations of identifiers? For codelists there are genericode and
CVA files. Is there an equivalent technology for identifier normative
representation? If not, maybe there should be.
I think of the classic example of a date: Not strictly an identifier
(a philosophical question, though) but it provides a useful example of
the need for normative representation in the ISO date format. I would
think of two examples of a date normative representation for today's
date (both with the YYYY-MM-DD format in mind) : without punctuation
20140415 and with punctuation 2014-04-15. The visual display could
'15th April 2014', 'April 15, 2014', etc, etc. There is then the
standard documented by ISO for it and there is the implementation of
that standard in W3C XML Schema as the date data type.
Perhaps there would be significant value in implementation guides
trying to provide something like the ISO date format when defining
identifiers used in UBL implementations. How to do it though?
'Generiform'? I guess normative formatting for identifiers is out of
scope for Genericode and the OASIS Codelist Representation TC.
There might be some merit in advocating / promoting a convention of
identifier normative representations excluding punctuation and white
space where possible, including it only when essential to distinguish
between different identifiers; and pushing all further formatting into
the display. That would be like representing bank sorts codes always
as xxxxxx (not xx-xx-xx) in the document XML.
Cheers
Steve
Best regards
Steve
---
Stephen D Green
On 14 April 2014 16:18, G. Ken Holman <gkholman@cranesoftwrights.com> wrote:
> No-one has brought it up yet, but I would think that every number would have
> a "normative" representation, that being how the number is presented in some
> kind of registration document.
>
> 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]