Package Grounding

[mkaplun]

Pretty self-explaining.

Correcting the error: unlike the current version of the SDCM, there is no association between the classes End Point and Interface.

[wznira]

I think two properties from SDCM 2.0 could be useful:

1. A reference from an End Point to the Interface. End Point is a physical web service that implements an abstract definition in the Interface. For example, everything defined in the SDS specification can be expressed using Interface - FAA and KAC SMXS will have the same Interface definition, but different grounding.
2. A machine readable description. I think a link to the OpenAPI or WSDL document can be very useful.

[caroluri]

From the model in SDCM 2.0 it would seem that a binding can involve more than one protocol document. E.g., the FPS service has 1 binding and 3 protocols. So you're saying that in the new model, FPS would have 3 bindings? Just asking.

[wznira]

From the model in SDCM 2.0 it would seem that a binding can involve more than one protocol document. E.g., the FPS service has 1 binding and 3 protocols. So you're saying that in the new model, FPS would have 3 bindings? Just asking.

I would think so. In WSDL, you can have multiple bindings referencing the same interface with each defining a different endpoint. I think it is also possible to have two bindings with the same protocol referencing the same interface. For example, one could have an HTTP endpoint for FPS on the FAA FTI network, and another HTTP endpoint for FPS on the public Internet.

[caroluri]

Last question: Can I assume the enumerated "types" the same as the current protocol types (data, message, transport, other)?

[mkaplun]

Here are my thoughts regarding the points made by @wznira.

1) I agree with what it's said in the first bullet, but all this doesn't negate the proposed design but rather affirms it. The SMXS interface for FAA and KAC are identical (due to the fact that they both follow the same specification), but their physical endpoints-- and, accordingly, Groundings -- are different.

2) A "machine readable description" is still a service description. In my opinion, it isn't a correct approach to put a service description, whether machine-processable or not, inside the proposed conceptual service description. It could be added as a reference to some instances of SDCM such as WSDD, but this is outside of the objectives of a conceptual model.

[mkaplun]

Here are my thoughts regarding the Grounding package structure and relationships discussed in the comments by @caroluri and @wznira.

My vision is that every service has one or more endpoints. Each endpoint can be accessed/used by deploying a collection of bindings.

For example, a NOTAM service may be accessible via the Internet (networking binding), using XML as a syntax (data binding) and relying on AIXM for information exchange. All these three binding allows using the endpoint as shown on the diagram.

If this model is valid, it could be conceptualized by the following diagram.

[wznira]

1. I agree with what it's said in the first bullet, but all this doesn't negate the proposed design but rather affirms it. The SMXS interface for FAA and KAC are identical (due to the fact that they both follow the same specification), but their physical endpoints-- and, accordingly, Groundings -- are different.

I agree.

2. A "machine readable description" is still a service description. In my opinion, it isn't a correct approach to put a service description, whether machine-processable or not, inside the proposed conceptual service description. It could be added as a reference to some instances of SDCM such as WSDD, but this is outside of the objectives of a conceptual model.

That makes sense.

[wznira]

If this model is valid, it could be conceptualized by the following diagram.

I like that network, data, information distinction 👍

It seems that the data protocol is more logically associated with the Payload(See issue) and the information protocol is more logically associated with the Data. Again, take the FAA and KAC SMXS example, they have the exact same data protocol (JSON) and exact same information protocol (SDM-J), which, as we discussed, are specified in the SDS specification and should be reflected in the Model part.

[mkaplun]

RE: @wznira comment.

There seems to be some contraction between

End Point is a physical web service that implements an abstract definition in the Interface.

and

It seems that the data protocol is more logically associated with the Payload(https://github.com/faa-swim/sdcm/issues/13#issuecomment-1332432673) and the information protocol is more logically associated with the Data. Again, take the FAA and KAC SMXS example, they have the exact same data protocol (JSON) and exact same information protocol (SDM-J), which, https://github.com/faa-swim/sdcm/issues/15#issuecomment-1335190835, are specified in the SDS specification and should be reflected in the Model part.

If the Model provides an abstract representation of an Interface, which I totally agree with, then it shouldn't include/define concrete protocols. In other words, a Model can be implemented by XML, JASON, and anything else, but the different binding should result in creating different endpoints.

Note: this is not so clear when describing RESTful services, but so far I don't see how to make a REST interface completely language-neuteral.

[caroluri]

With respect to the inclusion of machine readable description (e.g. WSDL) in SDCM: SDCM version 1.0 put it in the Profile, then version 2.0 put it in the Grounding. Even then there was some question. I agree that it should be a reference document (NSRR has a Service Document type = "Service WSDL") and not part of the SDCM.

With respect to protocols (Data protocol, Message protocol, Transport protocol), I agree that they are more logically associated with the Binding. However, we haven't talked about an "Information protocol" before; how the data is interpreted to create information should not differ for different bindings for a given service. That is, the data entities/fields that comprise the information provided by the service are defined and interpreted according to, e.g., AIXM regardless of the binding. The Package Model issue #13 says "Associated Data Definition class is replaced with the attribute 'source' of type Document that points to either the human or machine-processable document that defines the Data Entity (e.g., XML schema, data standard)." I believe something like AIXM or SDM-J would be just such a 'source' since it is used to interpret the meaning and structure of the Data.

[wznira]

(Sorry that I deleted @mkaplun's comments by mistake. Here is the original posting)

RE: @caroluri post.

When writing about "information protocol," I visualized a scenario where an SDMX may have two (or more) kinds of responses: one in JSON and one in XML. In this case, we will have two data protocols (XML and JSON), and the information exchange models will be SDM-X and SDM-J.

The TFMS was first written in a proprietary POX and later converted to FIXM; the schema (information model) had changed by everything else stayed the same.

The question to which I don't have a good answer myself is how to convey information about information models. Maybe the source attribute in the Data class may provide all the necessary information? But then it's interesting to think whether the information conveyed by the Representation class is redundant, considering that the source attribute describes the content and the language of data inside a Payload.

[wznira]

When writing about "information protocol," I visualized a scenario where an SDMX may have two (or more) kinds of responses: one in JSON and one in XML. In this case, we will have two data protocols (XML and JSON), and the information exchange models will be SDM-X and SDM-J.

If we follow this line of thinking, would not SDCM be the information protocol instead of SDM-J?

[caroluri]

Could a single service that offers the same information product represented in different formats at two different end points be one of those unusual services which has more than one Interface? In STD-065B and in STD-073A (for non-NEMS services), the requirement says "The (Binding) information SHALL include the name of the operation, and the name of an interface associated with this operation, that deploys this binding. NOTE: when all operations within the interface deploy the same binding, only the interface name is required." Keeping a reference to the Interface as Wen suggested earlier may be useful to accommodate these cases.

I believe the Source attribute in the Data class is the place to describe the information product(s) provided by the service in the form of data conveyed in the service's messages. Conceptual models and schemas give meaning to the data entities that make up the products, thereby creating "information" out of data.

[mkaplun]

I will try to answer the @caroluri comment and @wznira question in one comment. @wznira asked

If we follow this line of thinking, would not SDCM be the information protocol instead of SDM-J?

If we use an analogy with a Relational database, the SDCM is a conceptual model, while SDM-J is a physical model that one needs to build actual data (message payload). So, I don't think that collection of the definitions of terms and related UMLs can be used as an "information protocol" (in case we decide to have one.) @caroluri commented:

Could a single service that offers the same information product represented in different formats at two different end points be one of those unusual services which has more than one Interface? In STD-065B and in STD-073A (for non-NEMS services), the requirement says "The (Binding) information SHALL include the name of the operation, and the name of an interface associated with this operation, that deploys this binding. NOTE: when all operations within the interface deploy the same binding, only the interface name is required." Keeping a reference to the Interface as https://github.com/faa-swim/sdcm/issues/15#issuecomment-1332614275 may be useful to accommodate these cases.

I think we can add an attribute interface. interface (optional). The Interface's name indicating the interface for which binding information is being specified [WSDL 2.0].

I am not sure whether it's truly necessary, but we can do it.

[caroluri]

Agree with adding the attribute "interface". I also agree that conceptual models are not information protocols and don't belong here.

[wznira]

I agree as well

[mkaplun]