OASIS Code List Representation TC

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   Attachment: LanguageCode-gc-metamodel.xml Description: application/xml

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

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 ; 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 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    

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: > 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 -- 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