Ken,
Please forgive my delay in responding â I just returned to work after several weeks of traveling.
The NIEM metamodel may or may not be a good best fit for a genericode metamodel. The NIEM metamodel is intended to allow for abstract representations of both NIEM models (schema) and messages (instances). By âabstractâ, I mean that is not specific to or limited by specific formats such as XML, JSON, etc. ÂIn fact, the NIEM metamodel is self-describing (it defines itself).
My attempt was simply to determine which aspects/features of a genericode instance could be represented by the NIEM metamodel out of the box and to try to fill in any necessary extensions to fill in the gaps. If this works for instances, my next step would be to propose changes to the metamodel as needed to support these extensions.
__
Jim Cabral
502 509-4532
From: G. Ken Holman
Sent: Monday, July 12, 2021 12:18 PM
To: Jim Cabral;
Subject: Re: [codelist] NIEM metamodel extensions for gc
Forgive me, Jim, for taking so long to get to
your recommendation here. Finally this week I am
able to make time in preparation for Friday's
call (it has been a crazy start to summer for me, family-wise).
Thanks for putting in the time to mock up your
example ... I'm relieved it is only a mock-up and
that you have been awaiting feedback.
But I confess to be confused about this model
document you've put forward for consideration.
The document element says "Model", but the
content of the document says "instance" to me: it
actually includes an enumeration of language
values for the language code list. The file
expresses a list of codes, not a model from which
a list of codes is derived, nor an abstract model
from which the model of a list of codes is derived.
What I was thinking the committee needs is that
abstract model of the genericode model, not of specific genericode instances.
Considering my background in UBL, my train of
thought starts at the Core Component Technical
Specification (CCTS) 2.01, the abstract model of
the relationships between the members of a
hierarchy of business objects. Full stop. No
document models, no syntax, no instances, just
how members of a hierarchy are supposed to be
related to each other, and a base definition of
Core Component Types (CCT) on which the hierarchy is built.
The UBL committee then used CCTS to create the 91
semantic document models sharing the one common
library. The business objects in the UBL XSD
document models are instances of the CCTS
modeling concepts. The XML documents, in turn,
are instances of the UBL document models. The
OASIS Business Document Naming and Design Rules
govern how the abstract CCTS model creates the
XSD expressions of XML syntax constraints for the business documents.
The XML documents are not instances of CCTS,
though their elements exhibit properties of CCTS
that were realized in the UBL document models ... so that's a bit confusing.
When it came time to create the JSON syntax for
UBL documents, the committee did not
transliterate the XML instances or the XSD
models, rather, the OASIS Business Document
Naming and Design Rules were expanded to govern
how the abstract CCTS model creates the JSON
Schema expressions of JSON syntax constraints for the business documents.
So my question to the committee was, given that
we are starting in the "middle" of the modeling
chain with our existing XSDs that cannot change,
is there an abstract modeling language, perhaps
using NIEM, that is a step above the XSDs? Then
the genericode XSD that we already have would be
seen as a derivation of that higher-level
abstract model ... not the genericode XML, but the genericode XSD.
If we can show how the XSD is derived from the
higher-level model, then we can show how a JSON
Schema is derived from the higher-level model,
and then do so. Then we will have a set of JSON
Schema fragments that people can follow to create
JSON instances. We will know the semantics are
properly reflected in the JSON because it will
have been derived from the same higher-level
abstract model of what genericode means to be.
But I was only asking *if* such a higher-level
model can be done, and given my ignorance of
NIEM, is NIEM a way of modeling the concepts of
genericode such that we can derive the existing
genericode XSD schemas from that model? I was not
asking about a NIEM model of code list instances
... my bad for not being clear.
If NIEM is not appropriate, and we can't think of
anything else that is appropriate, not all is
lost. Erlend already has shown that we can
hand-craft a JSON Schema from what we see in a
subset of the XSD Schema such that, at the least,
we can give the community something to work with.
So I'm not disappointed if we haven't (yet) found
an meta-model for genericode, which is my
interpretation of the NIEM model that you posted.
We were lucky in UBL that the committee
(re-)started the semantic definitions twenty
years ago by using CCTS and did not model UBL
using XSD as the modeling language. I confess at
the time I was gobsmacked that a committee
creating XML wasn't using XSD, but I was a quick
convert to CCTS and the automation of the XSD
from the CCTS model. It opened my eyes.
Maybe I'm being a purist in my ivory tower hoping
to create a meta-model from which genericode XSD
and genericode JSON Schema both can be derived.
Just maybe it is a waste of time as we should
just plough ahead hand-crafting a genericode JSON
Schema the way the genericode XSD was hand-crafted.
But that is just my perspective of what I'm
seeing in the attached XML ... perhaps I'm
missing something and someone on the list can
clarify my misunderstanding. I haven't seen
anyone else yet comment on your contribution.
As always, I am welcome to be shown I'm wrong!
Please, members, share your thoughts on this
before Friday so that we can discuss Jim's contribution.
Thanks, again, Jim, for putting in this effort.
This is important stuff for us all to agree on.
. . . . . . . . Ken
At 2021-06-17 22:47 -0400, Jim Cabral wrote:
>I had an action item to consider extensions to
>the NIEM metamodel to support genericode
>features such as multiple columns and keys.
>
>
>
>Here is a mocked up example based on
>nc:LanguageCode that introduces 3 new elements to the NIEM metamodel:
>
>
>ÂÂÂ * HasColumn adds support for ColumnSets
>ÂÂÂ * HasKey adds support for key columns
> ÂÂÂ* Column replaces StringValue and DefinitionText inside the Enumerations
>
>
>
>If this looks good, IÃââll propose the necessary
>changes to the metamodel schema to implement
>these changes after I return from leave July 21.
>
>
>
>__
>
>Jim Cabral
>
>502 509-4532
>
>
>
>
>---------------------------------------------------------------------
>To unsubscribe from this mail list, you must leave the OASIS TC that
>generates this mail. Follow this link to all your TCs in OASIS at:
>https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
--
Contact info, blog, articles, etc. http://www.CraneSoftwrights.com/o/ |
Check our site for free XML, XSLT, XSL-FO and UBL developer resources |
Streaming hands-on XSLT/XPath 2 training class @US$125 (5 hours free) |
Essays (UBL, XML, etc.) http://www.linkedin.com/today/author/gkholman |
