[107] 本項で紹介するのは、 MIME型を更に細分化したものとしてのプロファイルを指定する
「profile」です。 Web Linking におけるリンク関係型として、
あるいは一部のMIME型の引数として使われています。
[90] プロファイルは、資源の表現を処理するために使うことができる制約、 表記法、拡張、 その他元々の媒体型の意味を変えないような追加の意味です (変えてはなりません)。 >>86
[89] 例えば podcast 用のプロファイルの URL を profile
リンクとして含めることで、クライアントはそのようなフィードを podcast
のフィードとして普通とは違った形で処理できます。 >>86
[92] プロファイルは組み合わせて使うことができ、 その場合クライアントが対応しているプロファイルについてそれぞれの異なる処理規則に従い当該資源の表現を処理することができます。 >>86
[87] プロファイルは URI によって識別されます。これは名前空間URLのようにプロファイルを識別するものであり、 必ずしも参照を解ける資源でなくても構いません。クライアントはこれをリンクとしてではなく識別子として扱うべきです。 >>86
[88] プロファイルの URL の参照を解くことによってプロファイルの人間可読または機械可読な説明の表現が得られるようになっていても構いません。 クライアントが未知のプロファイルの URL に遭遇するかもしれない状況では、 プロファイルの URL で有用な文書が得られるようにしておくべきです。 >>86
[123] JSON-LD では、プロファイル URLはdereference可能であるべきです >>120。
[94] 媒体型はその意味や表記を定義するものですが、しばしば拡張性を持っています。 プロファイルは媒体型の意味は変えずに追加の意味を定義するものです。 新しい媒体型とは違って、元の意味を全部変えてしまうわけではありません。 >>86
[95] 例えば XHTML は XML に対して新しい解釈を提供していて生 XML データを見せても意味が無いのでプロファイルではなく新しい媒体型です。 一方 hCard は HTML/XHTML の処理規則自体は変えずに追加の規則を定義しているので、 HTML/XHTML のプロファイルです。 >>86
[91] プロファイルは複数の媒体型にまたがって定義されるものであっても構いません。 資源の複数の表現に共通してプロファイルを関連付けることもできます。 とはいえクライアントはプロファイルを資源の表現に関連付けられたものとして扱うべきです。 >>86
profile (Web Linking)[114] リンク関係型 profile は、対象資源がプロファイルであることを表します。
[98] >>95, >>96 で RFC 6906 自体が示唆しているように、プロファイルの仕組みは
XML MIME型に対する屋上屋のように思えます。 >>97 の提案は profile
引数そのものです。
[140] また、提案されているように処理に大きく関わるものであるなら、 Link:
の一種として定義するよりも、独自のヘッダーとして定義する方がより利用しやすく、
実装時の間違いも起こりにくいように思えます。実際に利用したい場面があって、
著者や実装者がどう利用するのか、どうすれば正しく利用されるのかを検討して設計したのではなく、
Web Linking の仕組みの中で理論上あれば良いと考えられる機能を定義してみた、
というような顛末なのではないかと疑いたくもなります。 (本当に需要があるのなら、
もっと反響も利用例・実装例もありそうなものです。)
profile 引数 (MIME 型)[102] プロファイルが使えそうな媒体型を新しく定義する時は、
profile 引数を定義するべきです >>101。
[101] リンク型 profile のリンクは資源の表現に含まれるものなので、
その外側からは見えません。しかし profile 引数があれば、
Accept: ヘッダーによる内容折衝などで用いることができます。 >>100
[121] JSON-LD (application/ld+xml)
はこの profile 引数を採用しています >>120。
この引数は省略可能です >>120。
[132] Collection+JSON (application/vnd.collection+json)
もこの profile 引数を採用している模様です >>133。
[104] profile 引数を定義する時は空白で区切ったプロファイルの
URI のリストとするべきです。 >>100
[103] profile 引数を使う表現であっても、 profile
リンクは含めるべきです。これは、媒体型の引数は失われがちだからです。 >>100
[109] RFC 6906 は hCard と Dublin Core の DC-HTML を紹介していますが、
どちらもリンク関係型 profile における意味のプロファイルを定義していないので、
現時点で使うことはできません (使い方がわかりません)。
[111] RFC 6906 は iTunes の podcast の例も挙げていますが、 URL も含めすべてが例示に過ぎず、実際に使えるものではありません。
[112] 登録簿もなく好きな URL を使えるようですが、どこで誰が使っているのかわかりません。
[115] 2014年6月に発行された RFC 7284 は、 相互運用性のために有用である >>114 として、IANA登録簿 (>>127) を規定するものです。
[117] RFC 7284 は http://example.com/profiles/example
を例示しています >>114 が、この URL 自体は IANA に登録されていません。
かわりになぜか urn:example:profile-uri
を登録しています >>114。
[118] RFC 6906 で言及 (>>109) されていた DC-HTML の URL
http://dublincore.org/documents/2008/08/04/dc-html/
が登録されています >>114。ただし DC-HTML は HTML の
profile 属性の値を定義するもので、 Web Linking
における用法は DC-HTML も RFC 7284 も規定していません。
しかも HTML の profile 属性は現行の HTML Standard
では既に削除されていて、 DC-HTML はその後メンテナンスされていない、
既に実効性のない仕様です。このような値を登録したところで、
どのように使うつもりなのでしょうか (誰か使おうと思っている人はいるのでしょうか)。
[119] RFC 7284 は、更に、 JSON-LD >>120 を出典として3つの URL
を登録しています >>114。
[131] Go About API — Go About 3.16.3 documentation ( 版) <https://apidocs.goabout.com/>
では、
http://profiles.goabout.com/ からはじまるプロファイル
URL がいくつか定義されています。
[8] JSON-LD は、MIME型の引数の値として IRI を使えないため、 URI に変換する必要がある >>7 と述べています。普通プロファイル URL のように番地ではなく識別子として用いられる URL の場合、 不透明な文字列として扱うことになっています。 URI でない IRI だと意味が変わってしまう可能性が高いですが、なぜかそれには言及されていません。
profile 引数 (HTML、SMIL)[23]
XHTML の媒体型 application/xhtml+xml,
SMIL の媒体型 application/smil+xml,
application/smil
で定義されている引数 profile
は、名札付けされた実体が使用しているマーク付け言語のプロファイルを指定するものでした。
application/xhtml+xml,
application/smil+xml,
application/smilprofile
(profile (プロファイル) より)[41] 仕様書:
application/smil+xml,
application/smil)
<urn:ietf:rfc:4536> (IETF 情報提供 RFC)profile Optional Parameter[43]
この引数は、内容折衝で受信側の能力を示すために使う
(例えば Accept: で使う)
ことを想定しています。
特に、形式の変換を行う串が使うことを想定しています。
送信側が実体に名札付けするために使う
(例えば Content-Type: で使う) ことは想定していません。
RFC 4536 5.
[45]
profile 引数は、 CC/PP
が使われるようになるまでのつなぎです。
RFC 4536 5.
[29]
いくらつなぎ規格だからと言っても、提案している当の W3C の規格 (XHTML 1.0 とか 1.1 とか SMIL 2.0 とか SMIL Basic とか) の profile URI が規定されていないあたり、やる気がまったく感じられませぬ。
[80] WICD Full 1.0 ( ( 版)) <http://www.w3.org/TR/WICDFull/#identification>
[81] WICD Mobile 1.0 ( ( 版)) <http://www.w3.org/TR/WICDMobile/#identification>
[84] JSON-LD 1.0 ( ( 版)) <http://www.w3.org/TR/json-ld/#application-ld-json>
[85] draft-wilde-atom-profile-03 - Profile Support for the Atom Syndication Format ( ( 版)) <http://tools.ietf.org/html/draft-wilde-atom-profile-03>
[2] >>1 で W3C HTML5 において application/xhtml+xml
の profile 引数がなぜか非推奨ながら「復活」しています。
[13] http://www.wapforum.org/xhtml : XHTML Mobile Profile
(<http://www.openmobilealliance.org/wapdocs/wap-277-xhtmlmp-20011029-a.pdf> 7.2 参照)
[12] <http://www.geocities.co.jp/Hollywood-Studio/8691/>: <http://math.oheya.to/dtd/geo/geo-html11.dtd> の。
Accept: application/smil+xml; profile="http://www.w3.org/2001/SMIL20/HostLanguage"
[139] JSON Schema は、 application/json とその subtype
(+json のことか?) の profile
引数によってJSON SchemaのURLを指定するべきとしています >>138。
[134] JSON Reference は
application/json; profile=http://json-schema.org/json-ref
のような指定を使うべき >>135 と規定していましたが、
その後削除されています >>136。
[106] MIME型に対する制約としてのプロファイルは、HTMLメタ情報プロファイルに関する
head 要素の profile 属性と
(一部の人達により半ば意図的に) 混用されました。一部の XHTML1 仕様書は、
head 要素の profile 属性を本項の意味に (曖昧に)
定義していまして、 application/xhtml+xml の profile
引数もそうなっています。 XHTML2 のリンク型 profile や Web Linking
の一部として提案されていた Profile: ヘッダーも、そのような混用状態の延長線上にあるようです。
[128] RFC-6906-Profiles - DCMI_MediaWiki ( ( 版)) <http://wiki.dublincore.org/index.php/RFC-6906-Profiles>
[129] The ‘profile’ Link Relation and You ( ( 版)) <http://words.steveklabnik.com/the-profile-link-relation-and-you>
[130] JSON API :: Extending ( ( 版)) <http://jsonapi.org/extending/>
[6] ALPS (application/alps+xml, application/alps+json) も同様な profile
引数を定義していますが、 RFC は参照していないようです。
Responses can include the Link header[2] with the href value set to the URL of the ALPS profile document and the rel value set to "profile."
Link: http://alps.io/profiles/microblogging; rel="profile"
profile
A whitespace-separated list of IRIs identifying specific constraints or conventions that apply to an ALPS document. A profile must not change the semantics of the resource representation when processed without profile knowledge, so that clients both with and without knowledge of a profiled resource can safely use the same representation. The profile parameter may also be used by clients to express their preferences in the content negotiation process. It is recommended that profile IRIs are dereferenceable and provide useful documentation at that IRI.
[14] TTML も同じような profile 引数を定義しています。
TTML 本体に ttp:profile なる概念があり、
それと同じと定義されています。値はやはり URL です。
(RFC は参照していません。) codecs 引数と用途が重なり、
可能な場合 codecs 引数を使うよう指示されています。
<link rel="profile" href="http://gmpg.org/xfn/11">
[17] TTML Media Type Definition and Profile Registry () <https://www.w3.org/TR/2016/NOTE-ttml-profile-registry-20161006/>
[18] TTML Media Type Definition and Profile Registry () <https://www.w3.org/TR/2016/NOTE-ttml-profile-registry-20161009/>
"profile": If provided, this parameter indicates the GML profiles that the GML document conforms to. This is consistent with the semantics of a profile as laid out in RFC 6906.
The parameter can also be used to provide protocol-specific operations, such as profile-based content negotiation in HTTP.
A profile is identified by a URI.
As a GML document may conform to more than one GML profile, the parameter value is a whitespace-separated list of profile URIs.
Syntax:
profile = URI *( 1*WSP URI )
The element "URI" is defined by Section 3 of RFC 3986.
Profile URIs are assigned by the publisher of the GML profile. The URI should be in the "http" URI scheme and, if dereferenced, should return information about the GML profile.
For example, version 2.0 of the GML Simple Feature Level 0 profile specified by OGC is identified by the URI "http://www.opengis.net/def/profile/ogc/2.0/gml-sf0".
The media type of this format is defined in Section 3 of the Annotation Protocol [annotation-protocol] as application/ld+json;profile="http://www.w3.org/ns/anno.jsonld".
Servers must support the JSON-LD representation using the Web Annotation profile. These responses must have a Content-Type header with the application/ld+json media type, and it should have the Web Annotation profile IRI of http://www.w3.org/ns/anno.jsonld in the profile parameter.
Servers may support different JSON-LD profiles. Content negotiation for different JSON-LD profiles is performed by adding a profile parameter to the JSON-LD media type in a space separated, quoted list as part of the Accept header.
JSON-LD [json-ld] is the serialization format used in the Web Annotation Data Model [annotation-model]. HTML can accommodate this serialization format directly via the use of the HTML <script> element with its type attribute assigned the media type for a Web Annotation: application/ld+json;profile="http://www.w3.org/ns/anno.jsonld".
the body of the POST request must contain the notification payload in JSON-LD with header Content-Type: application/ld+json. The Content-Type header may include a profile URI [RFC6906].
Content-Type: application/ld+json;profile="https://www.w3.org/ns/activitystreams"
profile: The profile parameter for the application/activity+json media type allows one or more profile URIs to be specified. These profile URIs have the identifier semantics defined in [RFC6906]. The "profile" media type parameter must be quoted. It contains a non-empty list of space-separated URIs (the profile URIs).
profile-param = "profile=" profile-value
profile-value = <"> profile-URI 0*( 1*SP profile-URI ) <">
profile-URI = URI
The "URI" in the above grammar refers to the "URI" as defined in Section 3 of [RFC3986].
Because Activity Streams 2.0 can be considered a restricted profile of JSON-LD, Implementations should consider the `application/ld+json; profile="https://www.w3.org/ns/activitystreams"` media type as being equivalent to `application/activity+json`.
[30] Negotiating Profiles in HTTP () <http://profilenegotiation.github.io/I-D-Accept--Schema/I-D-accept-schema>
The compliance level URI may also be given in the HTTP Link header (RFC5988) with the parameter rel="profile", and thus a complete header might look like:
Link: <http://iiif.io/api/image/2/level1.json>;rel="profile"
MUST make an HTTP POST request to this URL with the Content-Type of application/ld+json; profile="https://www.w3.org/ns/activitystreams". Servers MAY interpret a Content-Type or Accept header of application/activity+json as equivalent to application/ld+json; profile="https://www.w3.org/ns/activitystreams" for client-to-server interactions.