[cvs-annodex] commit (/annodex):
standards/draft-pfeiffer-temporal-fragments-current.xml
silvia
nobody at lists.annodex.net
Sat Feb 26 14:47:28 EST 2005
Update of /annodex (new revision 959)
Modified files:
standards/draft-pfeiffer-temporal-fragments-current.xml
Log Message:
Changed:
- URI queries to be to different resources that the base resource
- time intervals always to be [x,x[
- fixed Accept-Ranges typo and replaced "please" with "bytes"
Modified: standards/draft-pfeiffer-temporal-fragments-current.xml
===================================================================
--- standards/draft-pfeiffer-temporal-fragments-current.xml 2005-02-26 01:01:17 UTC (rev 958)
+++ standards/draft-pfeiffer-temporal-fragments-current.xml 2005-02-26 03:47:10 UTC (rev 959)
@@ -78,7 +78,7 @@
<t>When a server (e.g. a Web Server) supports the URI query syntax
it is able to extract the given time
- subsections from the resource and serve that as another
+ subsections from the base resource and serve that as another
resource of the same type. Specifying a time point
or interval through a URI fragment in contrast does not deliver
a subpart of the resource - instead it is up to the
@@ -165,7 +165,7 @@
</t>
<t><xref target="URI">RFC 3986</xref> specifies that URI queries
-xxx identify a resource and thus a Web server MUST process the
+ identify a resource and thus a Web server MUST process the
query returning a fully defined resource. There is no
generically defined structure to URI queries. However, the
format of a CGI query string where name-value pairs are
@@ -502,17 +502,12 @@
and CMML has a tag for it.
</t>
-xxx <t>The semantic interpretation of temporal intervals depends on
- the time scheme. Unless specified differently, the temporal
- intervals given are closed intervals, starting at the
- first time point and finish at the second time point:
- [time_from;time_to]. For SMPTE timecodes, however, it is
- conventional to express such temporal intervals as IN and OUT
- times for editing. Thus, the IN time specifies the first frame
- that is included in the interval and the OUT time specifies the
- first frame that is not included in the interval. Therefore, a
- SMPTE interval is specified as [time_from;time_to[, which
- explains the additional frame in the above example.
+ <t>The semantic interpretation of temporal intervals is as
+ IN and OUT times like the conventions in use for editing
+ media content: [time_from;time_to[ . This means that the interval
+ stops just at the end time. The reasoning is that it just works
+ when concatenating two intervals that follow directly upon each
+ other.
</t>
</section>
@@ -527,14 +522,14 @@
<t>Time-continuous resources often come with high bandwidth
requirements, so a <xref target="HTTP">HTTP</xref> server
should serve out only the queried time interval of a
- resource to avoid unnecessary network load.
+ base resource to avoid unnecessary network load.
For example, a 1 hour Digital Video (DV format) requires about
25 GB (MPEG-2 reduces that to about 3 GB). It also significantly
reduces the delay for the user agent for receiving relevant data.
</t>
<t>A user agent that sends a URI that includes a temporal query
- to a HTTP server expects that server to return just the subparts
+ to a HTTP server expects the server to return just the subparts
of the base resource that it is querying for. It expects to be
notified by the server if the server cannot resolve the query
such that it may take appropriate action.
@@ -543,15 +538,14 @@
<t>The HTTP protocol specifies that a server has to return
a "404 not found" error message on URI requests which cannot be
resolved. A URI with a query component is a different URI than
- the same URI without a query component
-
-A URI request that contains a query component is a
-xxx relative URI which is being resolved relative to its base URI.
- Most current implementations of HTTP servers therefore support
- a somewhat non-conformant resolution of a URI request that
- contains a query component: if they cannot resolve the query,
- but the base URI can be resolved, they simply return the base
- resource. This makes it difficult for a user agent to find
+ the same URI without a query component, so if it cannot be
+ resolved, a "404 not found" is expected . However, most current
+ implementations of HTTP servers regard the query component as
+ a relative to the same URI without the query component and
+ therefore support a somewhat non-conformant resolution of such a
+ URI request: if they cannot resolve the query component,
+ they will try to resolve the same URI without the query component.
+ This makes it difficult for a user agent to find
out whether a temporal query component was actually resolved or not.
</t>
@@ -580,7 +574,8 @@
time-based Web resources, such as Annodex resources, are often
memory-intensive. User agents may more frequently request URIs
with temporal queries than the full resource. Therefore, a larger
- impact on bandwidth usage comes from caching the temporal URI queries.
+ impact on bandwidth usage comes from caching the temporal URI
+ queries as they are independent resources.
</t>
<t>The caching mechanism in HTTP/1.1 for subranges of a resource is
@@ -617,8 +612,8 @@
has processed the temporal URI query request.
</t>
- <t>The server will return the byte ranges that the user agent
- should ask for in another additional response header field:
+ <t>The server will return a list of the byte ranges that the user
+ agent should ask for in another additional response header field:
"X-Range-Redirect". It will also need to redirect the user agent
to another resource, which it provides in the "Location" header
field. Data that is specific to the URI request with the given
@@ -629,8 +624,8 @@
</t>
<t>After this, the user agent has all the information it requires
- to post another GET request, this time for the base URI only and
- including a "Range" request header field.
+ to post another GET request, this time for the base resource only
+ and including a "Range" request header field.
</t>
<t>In its response, the server includes the requested one or several
@@ -648,7 +643,7 @@
<artwork><![CDATA[
GET http://example.com/video.anx?t=npt:15.2 HTTP/1.1
Accept: application/x-annodex
-X-Accept-Range-Redirect: please
+X-Accept-Range-Redirect: bytes
]]></artwork>
</t>
<t>Server HTTP response:
@@ -659,7 +654,7 @@
Content-Type: application/x-annodex
X-Range-Redirect: 777-
Vary: X-Accept-Range-Redirect
-Accept-Range: bytes
+Accept-Ranges: bytes
Location: http://example.com/video.anx
X-Accept-TimeURI: application/x-annodex, text/x-cmml
@@ -681,7 +676,7 @@
Content-Type: application/x-annodex
Content-Range: bytes 777-
Vary: Range
-Accept-Range: bytes
+Accept-Ranges: bytes
X-Accept-TimeURI: application/x-annodex, text/x-cmml
Message body: video.anx from byte position 777 onwards
@@ -702,7 +697,7 @@
</t>
<artwork><![CDATA[
-X-Accept-Range-Redirect = "X-Accept-Range-Redirect" ":" "please"
+X-Accept-Range-Redirect = "X-Accept-Range-Redirect" ":" "bytes"
]]></artwork>
</section>
--
silvia
More information about the cvs-annodex
mailing list