OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

codelist message

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

Subject: RE: [codelist] NIEM metamodel extensions for gc

At 2021-07-21 11:57 -0400, Jim Cabral wrote:
Please forgive my delay in responding ? I just returned to work after severaal weeks of traveling.

Well done!

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).

I recall you teaching us that, yes.

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.

Ah, but my point is that I don't think the genericode committee needs this to be done for genericode instances. Our model for genericode instances is the XSD Tony created for our XML.

What I posited earlier, and we were considering at and minuted in our last meeting (but won't decide without debate with you) is abandoning the genericode metamodel because there is no interest in realizing in JSON those aspects of such a metamodel that go beyond the simple code list that everyone is using.

Please let me know what you think. The more we talk about this on the list, the less we have to talk about it during a meeting.

. . . . . Ken


Jim Cabral

502 509-4532

From: <mailto:gkholman@cranesoftwrights.com>G. Ken Holman
Sent: Monday, July 12, 2021 12:18 PM
To: <mailto:jim@cabral.org>Jim Cabral; <mailto:codelist@lists.oasis-open.org>codelist@lists.oasis-open.org
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 proposeose 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:



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 |

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 |

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