Home. 
.

transparent

transparent

transparent

Altova Mailing List Archives


Re: When to make a new vocabulary...

From: "G. Ken Holman" <gkholman@----------------.--->
To: <xmlschema-dev@--.--->
Date: 8/9/2007 7:34:00 AM
At 2007-08-09 08:34 -0400, Fortuno, Adam wrote:
>This is more of a philosophical question rather than a technical question.

I think these are welcome questions.

>I have a vocabulary that my company uses to express mortgage 
>transactions. As we look to move into consumer lending, this 
>vocabulary isn't sufficient. We don't have the markup needed to 
>express different types of collateral or unsecured lending.

Do you need new document structure to express these different types, 
or do you just need new coded values in code lists?

>It leaves us with two options: (1) build upon the existing 
>vocabulary to handle the new subject matter or (2) develop a new 
>vocabulary to handle the new subject matter.

What the Universal Business Language[1] did was separate the value 
validation of code lists and identifier lists from the structural 
validation of document structure and lexical structure.

The approach utilizes an OASIS specification named "genericode"[2] 
and itself is being standardized as a Schematron-based approach when 
using genericode in its own specification[3].  There is a case 
study[4] of a committee going through the steps of considering and 
deploying the specification.

>Consumer lending is different enough from mortgage lending that I 
>would prefer to develop a new vocabulary to handle it. However, 
>other believe strongly we should modify the existing schema.
>
>Has anyone else grappled with this sort of question? Can you offer 
>any advice based on your experiences? In what cases, does it make 
>sense to make separate vocabularies rather than one huge one?

Can you clarify by what *you* mean as vocabularies.  A document 
structure is an XML vocabulary.  A code list is often called a 
controlled vocabulary.

In UBL we wanted to standardize on the XML vocabulary, but not 
bake-in the code lists since not only would groups of UBL users want 
to use different code lists, but an individual might want to use 
different code lists than the group, and an individual might want to 
vary sets of codes between different trading partners.  In UBL this 
is all done with a foundation XSD schema for structural and lexical 
validation and a layer on top of value validation.  Since the value 
validation uses Schematron, arbitrary business rules can be cooked in 
with the code list values.

Regarding the structural validation and XSD schema, the committee is 
publishing customization guidelines.  Every one of the 31 schemas has 
an extension point for arbitrary extensions, so that a community of 
users can prescribe a deployment of UBL that is simultaneously a 
subset of standardized constructs and an extension of specialized 
constructs that at all times validates against the published UBL structures.

I hope this helps.

. . . . . . . . . . . . . Ken

[1] http://docs.oasis-open.org/ubl/os-UBL-2.0/UBL-2.0.html
[2] http://docs.oasis-open.org/codelist/genericode
[3] http://www.oasis-open.org/committees/document.php?document_id=24810
[4] http://www.oasis-open.org/committees/document.php?document_id=24813


--
Upcoming public training: XSLT/XSL-FO Sep 10, UBL/code lists Oct 1
World-wide corporate, govt. & user group XML, XSL and UBL training
RSS feeds:     publicly-available developer resources and training
G. Ken Holman                 mailto:gkholman@C...
Crane Softwrights Ltd.          http://www.CraneSoftwrights.com/x/
Box 266, Kars, Ontario CANADA K0A-2E0    +1(613)489-0999 (F:-0995)
Male Cancer Awareness Jul'07  http://www.CraneSoftwrights.com/x/bc
Legal business disclaimers:  http://www.CraneSoftwrights.com/legal


From boris@k... Fri Aug 10 18:16:24 2007
Received: from maggie.w3.org ([193.51.208.68])
	by frink.w3.org with 


transparent
Print
Mail
Like It
Disclaimer
.

These Archives are provided for informational purposes only and have been generated directly from the Altova mailing list archive system and are comprised of the lists set forth on www.altova.com/list/index.html. Therefore, Altova does not warrant or guarantee the accuracy, reliability, completeness, usefulness, non-infringement of intellectual property rights, or quality of any content on the Altova Mailing List Archive(s), regardless of who originates that content. You expressly understand and agree that you bear all risks associated with using or relying on that content. Altova will not be liable or responsible in any way for any content posted including, but not limited to, any errors or omissions in content, or for any losses or damage of any kind incurred as a result of the use of or reliance on any content. This disclaimer and limitation on liability is in addition to the disclaimers and limitations contained in the Website Terms of Use and elsewhere on the site.

.
.

transparent

transparent