adding ABNF info to HTTP header fields

dret · Aug 6, 2014 · fea7cac · fea7cac
1 parent 601b2cc
commit fea7cac
Show file tree

Hide file tree

Showing 3 changed files with 15 additions and 6 deletions.
diff --git a/IETF/I-D/draft-fielding-http-key.xml b/IETF/I-D/draft-fielding-http-key.xml
@@ -4,5 +4,6 @@
     <documentation source="http://tools.ietf.org/html/draft-fielding-http-key">The 'Key' header field for HTTP responses allows an origin server to describe the cache key for a negotiated response: a short algorithm that can be used upon later requests to determine if the same response is reusable. Key has the advantage of avoiding an additional round trip for validation whenever a new request differs slightly, but not significantly, from prior requests. Key also informs user agents of the request characteristics that might result in different content, which can be useful if the user agent is not sending Accept* fields in order to reduce the risk of fingerprinting.</documentation>
     <http-header def="Key">
         <documentation source="http://tools.ietf.org/html/draft-fielding-http-key#section-2">The "Key" response header field describes the request attributes that the server has used to select the current representation. As such, its semantics are similar to the "Vary" response header field, but it allows more fine-grained description, using "key modifiers". Caches can use this information as part of determining whether a stored response can be used to satisfy a given request. When a cache fully implements this mechanism, it MAY ignore the Vary response header field. Additionally, user agents can use this information to discover if additional request header fields might influence the resulting response.</documentation>
+        <ABNF src="http://tools.ietf.org/html/draft-fielding-http-key#section-2">Key = 1#field-name *( ";" parameter )</ABNF>
     </http-header>
 </service>
diff --git a/IETF/I-D/draft-grigorik-http-client-hints.xml b/IETF/I-D/draft-grigorik-http-client-hints.xml
@@ -4,5 +4,6 @@
     <documentation source="http://tools.ietf.org/html/draft-grigorik-http-client-hints">An increasing diversity of connected device form factors and software capabilities has created a need to deliver varying, or optimized content for each device. Client Hints can be used as input to proactive content negotiation; just as the Accept header allowed clients to indicate what formats they prefer, Client Hints allow clients to indicate a list of device and agent specific preferences.</documentation>
     <http-header def="CH">
         <documentation source="http://tools.ietf.org/html/draft-grigorik-http-client-hints#section-2">The "CH" request header field describes an example list of client preferences that the server can use to adapt and optimize the resource to satisfy a given request. The CH field-value is a comma-delimited list of header fields, and the field-name values are case insensitive.</documentation>
+        <ABNF src="http://tools.ietf.org/html/draft-grigorik-http-client-hints#section-2.1">client-hint-value = token | 1#parameter</ABNF>
     </http-header>
 </service>
diff --git a/core/sedola.xsd b/core/sedola.xsd
@@ -32,19 +32,16 @@
                                 <xs:element name="document" minOccurs="1" maxOccurs="unbounded">
                                     <xs:complexType>
                                         <xs:sequence>
-                                            <xs:group ref="title" minOccurs="0"
-                                                maxOccurs="unbounded"/>
-                                            <xs:group ref="descriptions" minOccurs="0"
-                                                maxOccurs="unbounded"/>
+                                            <xs:group ref="title" minOccurs="0" maxOccurs="unbounded"/>
+                                            <xs:group ref="descriptions" minOccurs="0" maxOccurs="unbounded"/>
                                         </xs:sequence>
                                         <xs:attribute ref="xml:id" use="optional"/>
                                         <xs:attribute name="vocabularies" use="optional">
                                             <xs:simpleType>
                                                 <xs:list itemType="xs:token"/>
                                             </xs:simpleType>
                                         </xs:attribute>
-                                        <xs:attribute name="profile" type="xs:NMTOKEN"
-                                            use="optional">
+                                        <xs:attribute name="profile" type="xs:NMTOKEN" use="optional">
                                             <xs:annotation>
                                                 <xs:documentation>A @profile attribute indicates that a media type's document is using a profile according to RFC 6906. It must refer to the ID of a profile that is declared in a profile element.</xs:documentation>
                                             </xs:annotation>
@@ -127,6 +124,7 @@
                             <xs:sequence>
                                 <!-- HTTP Headers need no title, their name should serve as their title. -->
                                 <xs:group ref="descriptions" minOccurs="0" maxOccurs="unbounded"/>
+                                <xs:element minOccurs="0" ref="ABNF"/>
                             </xs:sequence>
                             <xs:attribute name="def" use="optional" type="httpHeaderType"/>
                             <xs:attribute name="ref" use="optional" type="httpHeaderType"/>
@@ -241,4 +239,13 @@
             </xs:simpleType>
         </xs:union>
     </xs:simpleType>
+    <xs:element name="ABNF">
+        <xs:complexType>
+            <xs:simpleContent>
+                <xs:extension base="xs:string">
+                    <xs:attribute name="src" type="xs:anyURI" use="required"/>
+                </xs:extension>
+            </xs:simpleContent>
+        </xs:complexType>
+    </xs:element>
 </xs:schema>