- From: Ruben Verborgh via GitHub <sysbot+gh@w3.org>
- Date: Wed, 17 Jul 2019 07:25:07 +0000
- To: public-dxwg-wg@w3.org
> @smrgeoinfo suggested that > > > this IETF definition is that it defines 'profile' to only apply to profiles of MIME types-- certainly a narrower scope that our discussions here. > > @RubenVerborgh refuted that Indeed. The definition says that profiles provide constraints in addition to those provided by more generic MIME types. For example, there could be a profile saying "use FOAF to represent people" and that profile could apply to text/turtle, application/ld+json, etc. Furthermore, there is nothing that says that profiles could not work together, and thus constrain each other. So there is a flexible relationship between profiles and MIME types; this definition just separates one from the other (which is not the case of some of the other proposed profile definitions). > Does this part include or exclude the JSON-LD profiles that are different from our profiles An IETF profile can be a JSON-LD profile; we don't see any reason to restrict it. But the DXWG definition can be stricter than the IETF definition, so not a problem. (I do have a [problem](https://github.com/w3c/dxwg/issues/976#issuecomment-512134251) with the exclusion of JSON-LD profiles, to the point I will be making below.) > Can you give examples of "structural contraints that wouldn't be semantic constraints nor syntactical constraint? Also see earlier thinking on https://ruben.verborgh.org/articles/fine-grained-content-negotiation/#where-mime-types-fall-short The difference between structure and syntax is not black and white, but where I draw the line is "would I need a different parser?". For instance, a JSON document for which specific keys are required, would likely still be parsed with a JSON parser, not with a custom one. Hence, I see JSON as a MIME type, and the requirement of specific keys as a profile. - Structure examples: - arrays can only contain numbers - objects can be nested up to 2 levels deep - only certain keys are allowed in certain places - Semantic examples: - the value under the key "prev" has the interpretation of a back link - the value under the key "pages" indicates the total number of pages > Maybe a reference to a definition for "structural" would help here. Constraints about what constitutes a valid (not "meaningful") document that are not covered by the parser corresponding to the MIME type. -- GitHub Notification of comment by RubenVerborgh Please view or discuss this issue at https://github.com/w3c/dxwg/issues/1002#issuecomment-512136552 using your GitHub account
Received on Wednesday, 17 July 2019 07:25:09 UTC