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: Published Subject Identifiers and Indicators for UBL 2.x


At 2007-12-11 00:06 -0800, jon.bosak@sun.com wrote:
>MINUTES OF PACIFIC UBL TC MEETING
>TUESDAY 11 DECEMBER 2007
>...
>OTHER BUSINESS
>
>    GKH: Request that we include ISO Public Subject Indicators
>    (PSIs) for all UBL constructs as a deliverable for UBL 2.1.
>    Background: a PSI is a URI that resolves to a human-readable
>    document describing a particular semantic, thus enabling the
>    subject to be unambiguously referenced in a Topic Map (ISO
>    13250).  JB committed to providing PSIs for UBL 1.0 a couple of
>    years ago but didn't find the resources to do it.  Assuming
>    that the semantics of UBL 2 will not change during the 2.x life
>    cycle (modulo minor corrections to the definitions), we propose
>    to create official PSIs for every UBL construct.
>
>    AGREED to add this item to the list of deliverables with GKH as
>    the person who will synthesize about 2000 XHTML pages from
>    spreadsheets, each page keyed to a unique Dictionary Entry Name
>    (DEN) and representing the columns of each entry as bullets on
>    its PSI page, the pages to eventually be archived at
>    psi.oasis-open.org/ubl2/ (see psi.oasis-open.org for the
>    beginnings of the OASIS PSI repository).

I don't think we have to wait until either 2.0 update or 2.1 ... I'm 
of the opinion that these resources can be published at any time 
(including the current incorrectly-documented semantics as initial 
placeholders), because the semantics never *change*, only their 
documentation can be improved.  We are never removing any construct 
from UBL 2.x, and the semantic of an information item in UBL 2.0 is 
going to be the same as in UBL 2.x, just the documentation in 2.x for 
that semantic might be an improved definition.

After every release I plan to push the button and recreate the /ubl2/ 
directory to give to the OASIS web folks to post.

So, I'm thinking of making the identifiers along the lines of:

   http://psi.oasis-open.org/ubl2/Address.Details/
   http://psi.oasis-open.org/ubl2/Address.Identifier/
   http://psi.oasis-open.org/ubl2/Address.AddressTypeCode.Code/
   http://psi.oasis-open.org/ubl2/Address.AddressFormatCode.Code/
   http://psi.oasis-open.org/ubl2/Address.Postbox.Text/
   http://psi.oasis-open.org/ubl2/Address.Floor.Text/
   http://psi.oasis-open.org/ubl2/Address.Room.Text/
   http://psi.oasis-open.org/ubl2/Address.StreetName.Name/
   http://psi.oasis-open.org/ubl2/Address.Additional_StreetName.Name/
   http://psi.oasis-open.org/ubl2/Address.BlockName.Name/

The indicators would then be the files:

   http://psi.oasis-open.org/ubl2/Address.Details/index.html
   http://psi.oasis-open.org/ubl2/Address.Identifier/index.html
   http://psi.oasis-open.org/ubl2/Address.AddressTypeCode.Code/index.html
   http://psi.oasis-open.org/ubl2/Address.AddressFormatCode.Code/index.html
   http://psi.oasis-open.org/ubl2/Address.Postbox.Text/index.html
   http://psi.oasis-open.org/ubl2/Address.Floor.Text/index.html
   http://psi.oasis-open.org/ubl2/Address.Room.Text/index.html
   http://psi.oasis-open.org/ubl2/Address.StreetName.Name/index.html
   http://psi.oasis-open.org/ubl2/Address.Additional_StreetName.Name/index.html
   http://psi.oasis-open.org/ubl2/Address.BlockName.Name/index.html

As I see it there are no versioning issues ... any old replaced 
version need not be preserved because it is being replaced because it 
is wrong.  When a 2.x set of files is created, definitions from 
earlier releases may get replaced, but the old objects retain their 
old semantics as intended by the group.

The first version of the indicators will merely be a dump of the 
spreadsheet columns associated with the item.  If users want more 
information in the indicator, we can look at changing that in the 
future.  The identifiers will not change, nor will they be versioned 
... which is critically important in Topic Map applications ... these 
have to be stable.  The content can change, and I see no reason to 
keep old content around.

In parallel I'm working with Robin Cover to ensure no OASIS policies 
or practices are being hurt by the making of this proposal.  The 
details of the above may have to change, and if they do so, I'll make 
a record in this mail list.

Thanks!

. . . . . . . . . . Ken

p.s. thanks, Jon, for putting into the Atlantic minutes the excerpted 
definitions of terminology


--
Comprehensive in-depth XSLT2/XSL-FO1.1 classes: Austin TX,Jan-2008
World-wide corporate, govt. & user group XML, XSL and UBL training
RSS feeds:     publicly-available developer resources and 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 Nov'07  http://www.CraneSoftwrights.com/o/bc
Legal business disclaimers:  http://www.CraneSoftwrights.com/legal



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