search

opengeospatial / D040-Complex_Feature_Handling_Engineering_Report

Deliverable for Testbed 14
http://www.github.com/opengeospatial/D040-Complex_Feature_Handling_Engineering_Report
Other
0 stars 3 forks source link

New media types or conneg by profile #6

Open lvdbrink opened 5 years ago

lvdbrink commented 5 years ago

I'm aware that the testbed has been concluded but upon reading of the finalized report of the work, I have a suggestion to make.

Recommendation 7 of the published ER states:

Register media types for encodings to be used in Web APIs. The selection of the data format used in a response must support HTTP content negotiation. This requires that format can be identified using media types that should be registered with IANA. For example, media types should be registered for i3s, 3D Tiles, CityJSON and perhaps also for CityGML.

I wonder if instead of doing this, the new idea developed at W3C for content negotiation by profile might be used - at least for encodings like CityJSON and CityGML.

cportele commented 5 years ago

Thanks, Linda. The report will stay as it is, but the follow-ups need to be done by the Standards Program anyhow and will be discussed there.

My main test with your proposal would be, if we run into problems with any systems that do not implement/support conneg-by-profile. Where that is the case, I would still consider registering media types.

cmheazel commented 5 years ago

@lvdbrink Would you open this issue in the OAPI-Common repository? I think it is relevant to all of our API work. My favorite use case - a base-64 encoding of the digital signature (encrypted) of an XML encoding of a GML-based schema implementing the NSG content model. To process a response I need to know every part of this layer-cake. Or better yet, make it a JSON encoding of a GML-based schema.

cnreediii commented 5 years ago

I agree that tracking the W3C work is a good idea but I also suggest proceeding with cautious optimism. Rob's (and others) work is in very draft form with many issue to be resolved. I am no expert in this technical area, but from the document:

Currently, the convention in HTTP content negotiation by media type uses tokens for Media Types, such as text/html or application/ld+json with the tokens registered at IANA's Media Types list http://www.iana.org/assignments/media-types.

Hopefully the draft addresses these issues. In any case, IANA media types will be around for a very long time and I concur with Clemens' suggestion.

Regards

Carl

On Tue, Mar 19, 2019 at 9:04 AM Chuck Heazel notifications@github.com wrote:

@lvdbrink https://github.com/lvdbrink Would you open this issue in the OAPI-Common repository? I think it is relevant to all of our API work. My favorite use case - a base-64 encoding of the digital signature (encrypted) of an XML encoding of a GML-based schema implementing the NSG content model. To process a response I need to know every part of this layer-cake. Or better yet, make it a JSON encoding of a GML-based schema.

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/opengeospatial/D040-Complex_Feature_Handling_Engineering_Report/issues/6#issuecomment-474411343, or mute the thread https://github.com/notifications/unsubscribe-auth/AMvMqyFIf4st_b3B7GXnV6zKwYl1ddgDks5vYPxsgaJpZM4b8QVy .

-- Carl Reed, PhD Carl Reed and Associates

Mobile: 970-402-0284

“Our liberty depends on the freedom of the press, and that cannot be limited without being lost.”

"I never considered a difference of opinion in politics, in religion, in philosophy, as cause for withdrawing from a friend"

— Thomas Jefferson, U.S. Founding Father

lvdbrink commented 5 years ago

@cmheazel done, see https://github.com/opengeospatial/oapi_common/issues/8