[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [codelist] NIEM metamodel extensions for gc
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 EnumerationsIf 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 |
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]