gmane.org.w3c.uri

URI Templates update

Mark Nottingham — 2012-05-17T11:28:11

Hi URI people,

Just a few notes regarding URI Templates, since we have an RFC now <http://tools.ietf.org/html/rfc6570>:

* Joe's implementation in Python has been moved to Github, and we've got it up to RFC level 4 conformance. See <https://github.com/uri-templates/uritemplate-py>. It's also now listed in pypi <http://pypi.python.org/pypi/uritemplate/0.5.1>. Note that it's still beta-quality; it doesn't do much in the way of input checking, for example.

* We've also started collecting test cases at <https://github.com/uri-templates/uritemplate-test>. Right now it includes the examples from the RFC, but we've been talking with other implementers about adding more; please make a pull request or raise an issue as appropriate. Note that the Python implementation above uses these for its testing.

* Finally, the list of implementations at <http://code.google.com/p/uri-templates/wiki/Implementations> has been updated. If you have more information about one of them, or would like one added, please make a comment there.

Cheers,

--
Mark Nottingham   http://www.mnot.net/

Fw: 6MAN WG Last Call: draft-ietf-6man-uri-zoneid-00.txt

t.petch — 2012-03-06T15:38:06

For those with an interest in the ABNFing of URI who have not seen this on the
IETF uri-review or on ipv6 lists, the question is how to tack an ipv6 zoneid
onto the constructs in RFC3986, while preserving the long standing ipv6 practice
of using a percent character as the separator in this case.

I would suggest follow-up on one of the two afore mentioned lists.

Tom Petch

----- Original Message -----
From: "Bill Fenner" <fenner< at >fenron.net>
To: "Brian E Carpenter" <brian.e.carpenter< at >gmail.com>
Cc: <ipv6< at >ietf.org>; "Brian Haberman" <brian< at >innovationslab.net>; "S Moonesamy"
<sm+ietf< at >elandsys.com>; <ipv6-chairs< at >tools.ietf.org>
Sent: Tuesday, March 06, 2012 1:08 PM
Subject: Re: 6MAN WG Last Call: draft-ietf-6man-uri-zoneid-00.txt


On Mon, Mar 5, 2012 at 7:15 PM, Brian E Carpenter
<brian.e.carpenter< at >gmail.com> wrote:
ways).

Previous joint work between the ipv6 working group and the W3C URI
working group resulted in a decision that did not change the ABNF at
all, in 2 ways:

1. It used the IPvFuture extension mechanism;
2. It used a non-percent character for the separator.

At the time, the URI working group was very concerned about the change
in the ABNF and the use of percent where percent had not previously
been allowed.  Have they changed their position here, or have they not
had a chance to comment on this change yet?

This work was accepted as an ipv6 wg work item around IETF63 (Paris,
2005), but the authors never pushed the document forward due to a lack
of interest in the broader community.  The draft that was adopted by
the wg was

http://tools.ietf.org/html/draft-fenner-literal-zone-01

  Bill
--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6< at >ietf.org
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------

http+aes

Julian Reschke — 2012-03-05T10:21:06

FYI:

http://dev.w3.org/html5/spec/Overview.html#http-aes-scheme

URI ACR extension

2012-03-02T13:05:30

Dear all.

I would like to bring your attention the http://tools.ietf.org/html/draft-uri-acr-extension-04  submission.

Technical summary:

   This URI scheme is intended as an extension to the "tel:"
   scheme but without disclosing the true identity of a reference or a
   user.  The "acr" URI describes an anonymous reference, that can be
   mapped to a resource or a user.  There are multiple situations where
   the true identity of a user or a resources can not be disclosed.  The
   "acr" URI is a globally unique identifier ( "name" ) only; it does
   not describe the steps necessary to reach the user or the device.
   However it can contain a parameter indication what body or
   organisation that could resolve it.  It is intended for privacy
   protection, where a user trusts a translating party, that can route
   or forward the request or message to the true user or resource.

This is an individual contribution, so I need help to bring this to a working group, and hopefully convert it to a permanent RFC in time.

Open Mobile Alliance is using this on multiple network enablers, to allow anonymous access to API's

Any advice would be helpful. :)


BR Sune Jakobsson

URI Template spec has been approved

Roy T. Fielding — 2012-02-04T00:55:08

Hello folks,

It seems that I need to close the loop, since the independent
submission process doesn't feed back here (unlike an open WG).

After a large number of constructive last call comments and
a draft 08 to address them

  http://www.ietf.org/internet-drafts/draft-gregorio-uritemplate-08.txt

the spec has been approved by the IESG as a Proposed Standard.
Now we just have to wait for the RFC Editor queue to get final
wording edits and publish it.

A diff from 07 is at

  http://uri-templates.googlecode.com/svn/trunk/spec/draft-gregorio-uritemplate-08-from-7.diff.html

Note that the one substantive change is the processing of
{;list*}, {?list*}, and {&list*} to allow for repeated
parameters with the same name, based on an earlier discussion
here.  Happy implementing.

Cheers,

Roy T. Fielding                     <http://roy.gbiv.com/>
Principal Scientist, Adobe Systems  <http://adobe.com/enterprise>

Begin forwarded message:


Begin forwarded message:

URI-Templates: "^" allowed in literals or not?

Peter Johanson — 2011-12-05T17:40:28

I have been working on an implementation of URI Templates in C#, and
came upon some ambiguity in the spec. In section 2.1 Literals, the ABNF
includes %x5D-5F in the set for literals, but the comment mentions that
literals should be 'any Unicode character except ... , "^", .. ' but "^" is
%x5E. Is "^" in the set of literals or no?

Thanks in advance,
-pete

ANN: NLP Interchange Format (NIF) 1.0 Spec, Demo and Reference Implementation

Sebastian Hellmann — 2011-11-28T07:43:46

Dear all,
we discussed the URI schemes on this list and I wanted to give some 
short feedback, how it turned out.
In a nutshell, I benchmarked if the URLs are stable between Wikipedia 
revisions and it turned out that the context-hash based approach had 
quite high probability (80-90 %) to stay stable between the revisions. 
Details can be found in the technical report.
All the best,
Sebastian



***ANNOUNCEMENT***
The Natural Language Processing Interchange Format (NIF) is an 
RDF/OWL-based format that aims to achieve interoperability between 
Natural Language Processing (NLP) tools, language resources and 
annotations. The core of NIF consists of a vocabulary, which can 
represent Strings as RDF resources. A special URI Design is used to 
pinpoint annotations to a part of a document. These URIs can then be 
used to attach arbitrary annotations to the respective character 
sequence. Employing these URIs, annotations can be published on the Web 
as Linked Data and interchanged between different NLP tools and 
applications.

In order to simplify the combination of tools, improve their 
interoperability and facilitating the use of Linked Data we developed 
the NLP Interchange Format (NIF). NIF addresses the interoperability 
problem on three layers: the structural, conceptual and access layer. 
NIF is based on a Linked Data enabled URI scheme for identifying 
elements in (hyper-) texts (structural layer) and a comprehensive 
ontology for describing common NLP terms and concepts (conceptual 
layer). NIF-aware applications will produce output (and possibly also 
consume input) adhering to the NIF ontology as REST services (access 
layer). Other than more centralized solutions such as UIMA and GATE, NIF 
enables the creation of heterogeneous, distributed and loosely coupled 
NLP applications, which use the Web as an integration platform. Another 
benefit is, that a NIF wrapper has to be only created once for a 
particular tool, but enables the tool to interoperate with a potentially 
large number of other
tools without additional adaptations. Ultimately, we envision an 
ecosystem of NLP tools and services to emerge using NIF for exchanging 
and integrating rich annotations.

We designed NIF to be very light-weight and to reduce the amount of 
triples to achieve better scalability. The following triples in N3 
Syntax express that the string “W3C” on 
http://www.w3.org/DesignIssues/LinkedData.html (index 22849 to 22852) is 
linked to the DBpedia resource of “World_Wide_Web_Consortium”:

< at >prefix ld: <http://www.w3.org/DesignIssues/LinkedData.html#> .
< at >prefix str: <http://nlp2rdf.lod2.eu/schema/string/> .
< at >prefix dbo: <http://dbpedia.org/ontology/> .
< at >prefix scms: <http://ns.aksw.org/scms/> .
< at >prefix nerd: <http://nerd.eurecom.fr/ontology#> .
ld:offset_22849_22852_W3C str:anchorOf "W3C" .
ld:offset_22849_22852_W3C scms:means dbpedia:World_Wide_Web_Consortium .
ld:offset_22849_22852_W3C a dbo:Organisation , nerd:Organization .

NIF already incorporates the Ontologies of Linguistic Annotation (OLiA, 
http://nachhalt.sfb632.uni-potsdam.de/owl/) and the Named Entity 
Recognition and Disambiguation (NERD, http://nerd.eurecom.fr/ontology/) 
ontology. Please get in contact, if you know of further NLP ontologies, 
which we can reuse and integrate in NIF.

This release consists of the following items:
1. The specification of NIF 1.0 ( http://nlp2rdf.org/nif-1-0 ) This 
document will guide the further implementation of NIF-enabled services. 
An average wrapper requires around 200-500 lines of code. The spec 
integrates several domain ontologies (OLiA, NERD) and will be extended 
in the future to cover more domains.
2. A community portal ( http://nlp2rdf.org )

TTLs for templates

Murray S. Kucherawy — 2011-10-25T14:56:25

What general guidance is there on how often one should query for a template from a well-known URI, in case it changes?  A long-running client might have trouble if the server wants a new template for some reason, and the client doesn't know it should get a new one.

-MSK

Another idea for URI templates

Murray S. Kucherawy — 2011-10-25T09:46:34

Hi all,

I don't have the URI template draft handy unfortunately (on a long flight), so I can't confirm this, but I think I found something useful that I don't believe the template draft currently handles.

If you have a template that includes "/{foo}", then the "/" is always inserted into the template regardless of whether or not "foo" is actually defined.  It might be nice to have the "/" be there only if "foo" is set.  Maybe something like "{?foo/}", which means:


-          If "foo" is not set, append the empty string.

-          If "foo" is set but empty, append "/" and the name "foo" only.

-          If "foo" is set to a string, append "/", then the name, then "=", then the value.

-          If "foo" is set to a list, append "/", then the name, then "=", then the list elements separated by ",".

-          If "foo" is set to a key-value set, append "/", then the first key, then "=", then the first value; for all remaining key-value pairs, append "&", the next key, then "=", then its matching value. (The name is not actually inserted into the template.)

So then a template of http://example.com/query.php{?foo?}<http://example.com/query.php%7b?foo?%7d> expands thus:


-          "foo" undefined: http://example.com/query.php

-          "foo" defined, but empty: http://example.com/query.php?foo

-          "foo" defined to string "bar": http://example.com/query.php?foo=bar

-          "foo" defined to list "a,b,c": http://example.com/query.php?foo=a,b,c

-          "foo" defined to key-value set "{a, 1}, {b, 2}, {c, 3}": http://example.com/query.php?a=1&b=2&c=3

Am I wrong, and the URI template spec handles this?  Or does this warrant some consideration and development?

Thanks,
-MSK

URI scheme best practices

Bob Van Zant — 2011-10-07T16:07:59

Hello everyone,
I've been reading through RFC 4395 and some of the mailing list
archives. We're working on iOS and Android apps that we'd like to have
be able to respond to URIs in the mail applications of each of those
devices. For example, if we generate a password reset email and send
it to the user and they click on that link in their mail application
we'd like that to fire up our app instead of the web browser.

I recognize that this is a fairly standard thing to do and in reading
through what must be a somewhat memorable thread (fb: URIs?
http://lists.w3.org/Archives/Public/uri/2010Feb/0013.html) I see that
this has been beaten around a bit.

Based on the fb: URIs thread I get the feeling that people wish we
could register with iOS and Android to have our app handle URIs of the
form http://www.eventbrite.com/resetpassword. I'm pretty sure that
this is not possible?

Given that we don't think we can use http and given RFC 4395 we're
planning to use a scheme com-eventbrite-attendee: and generate URIs
like com-eventbrite-attendee:resetpassword?parameters&go&here

Is this the current best practice? Is the intent of 4395 that we
attempt registration of the scheme com-eventbrite-attendee:? I'm happy
to go through the process described in section 5 of 4395 but the
extremely tiny URI scheme registration list almost makes me think that
IANA doesn't want us in there.

Thanks,

Bob

URI templates: commas

James Manger — 2011-09-07T15:13:14

Commas don't have a particularly special role in URIs. They are just 1 of 11 characters in the <reserved> set that are not used as delimiters of the generic URI components.

URI templates (draft-gregorio-uritemplate-06), however, gives commas special meaning. They are the only <reserved> character that can appear when expanding {var}.

I'm not aware of any reason why URI templates should single out commas for this special treatment.
It simultaneously encourages servers to use commas as separators, while also causing problems for some servers that have (quite reasonably) chosen to use commas as separators.

Consider a bank server that accepts payment transactions such as:
https://example.com/pay/{amount},{to},{from},{comment}

The template processor might be a trusted front-end inserting the "from" variable value based on the authenticated user, but accepting "amount" and "to" values from the user.
This should be able to be safe. But it isn't with the current draft spec.
If the user provides a "to" value that is actually a list [ "me", "victim" ] then the expansion puts the second "to" value where the bank was expecting the "from" account -- and a fraudulent transaction occurs.

Perhaps the bank could switch to using a different delimiter -- but that rather defeats one of the purposes of URI templates of being able to match the server's choice of URI structure.

If the server can provide extra information *outside of the template* about which variables are mandatory, which can or cannot be lists, and which can or cannot be composite values, then it may be able to avoid these problems. But templates should be usable without those limitations.

Almost any URI structure using commas as delimiters can face problems with even the most basic level 1 templates since the server cannot distinguish a comma from expanding a user-provided value from a comma that was a literal expression delimiter in the template.

I suggest that commas not be given special treatment by URI templates.
Expanding {var} should only be able to produce <unreserved> and <pct-encoded> characters -- regardless of the variable values a user provides.

--
James Manger

Uri Templates: Questions on draft-gregorio-uritemplate-06

Robbie Gates — 2011-09-05T07:54:36

Hi All,
 i am having trouble reconciling some of the examples in the 06 draft
with both the descriptions of the expansions and the sample
implementation.

The first set hinge on the handling of expansions where named (in the
sense of the table in appendix A) is true. The variable list has the
list value ["red", "green", "blue"]. The example expansions are:

        {;list}        ;list=red,green,blue
        {;list*}        ;red;green;blue
        {?list}        ?list=red,green,blue
        {?list*}        ?list=red&list=green&list=blue
        {&list}        &list=red,green,blue
        {&list*}        &list=red&list=green&list=blue

I don't understand why the expansions of ? and & include list= for
each entry when exploded. The description of the handling for the case
of an exploded list makes no mention of the use of the name, and there
is no separate section (as there is for the unexploded case). Also,
the table makes ; the same as ? and & for named, and yet their
handling appears different. The descriptions in 3.2.7 and 3.2.8 /
3.2.9 are likewise similar. In short, i can't see why the examples
differ, given the rest of the document, i was expecting

        {?list*}        ?red&green&blue
        {&list*}        &red&green&blue

I know these don't look like valid form query or form continuation
strings - am i missing something in the description of ? and & (and
the implementation hints) regarding special handling for the name when
exploded ?

The second case is the examples for the variable foo with string value
"That's right!"

        {foo}        That%27s%20right%21
        {+foo}        That%27s%20right!
        {#foo}        #That%27s%20right!

As far as i can see, the single quote character between the t and the
s is in sub-delims (in section 1.5) between & and (. I don't
understand why it is treated differently to ! which is also in
sub-delims. I would have expected these last two expansions to be:

        {+foo}        That's%20right!
        {#foo}        #That's%20right!

since both + and # have allow U+R, and ', ! (but not space) are
sub-delims and hence reserved.

Thanks in advance for any enlightenment,

 - Robbie

URI templates: comma-separated variable lists

James Manger — 2011-08-24T13:50:00

draft-gregorio-uritemplate-06.txt allows a comma-separated list of variables in any expression, regardless of the expression operator.

However, a list should not be used with 5 of the 8 operators (+ # . / and no operator) because an expansion will be ambiguous if any variable in the list is undefined. The server cannot tell which value goes with which variable.

Consider if the template "{alpha,beta,gamma}" is expanded to "23,6". The user could have provided alpha=23 beta=6, or alpha=23 gamma=6, or beta=23 gamma=6 (or beta=[23,6] but that is a separate bug).

A template like "{alpha,beta,gamma}" is almost certainly a mistake by the template author. It only makes any sense if all the variables are mandatory, but in that case it is clearer to use "{alpha},{beta},{gamma}" -- with no chance of ambiguity (and simpler lower-level expressions).

I suggest changing the spec ABNF to only allow variable lists with operators that produce name=value pair (or drop variable lists entirely).

--
James Manger

Fwd: Re: Document fragment vocabulary

Sebastian Hellmann — 2011-08-16T08:36:47

Dear all,
a topic came up on public-lod< at >w3.org , which might best be posted here.
I will summarize most of it here real quick, the details can be found
attached.

Currently, I am working on an interchange format in RDF for Natural
Language Processing(NLP), called NIF [1] (slides[2]), which is part of
LOD2[3].
It heavily relies on URI Fragment IDs that address substrings of a
plain/text document.
Although RFC5147 [4] exists it does not cover some requirements of the
NLP Use Case.

RFC5147 provides integrity checks, but there is no proposal that
produces robust fragment IDs. e.g. something that works on the context
and not on line or position. A change in the document on position 0
might render all fragment ids obsolete. E.g. "#range=(574,585)" would
not be valid any more, if one character was inserted at the beginning of
the document, changing the index.
The RFC was already extended for CSV[5], but I would even go further and
allow more extension and then collect them all in a structured format
such as an RDF/OWL vocabulary. We have already done this for our cases [6]

For our purposes, we defined 2 fragment recipes, in this case to
annotate the third occurrence of "Semantic Web":
http://www.w3.org/DesignIssues/LinkedData.html#offset__Semantic+Web_14406-14418
http://www.w3.org/DesignIssues/LinkedData.html#hash_md5_4__12_Semantic+Web_abeb272fe2deadd2cd486c4cea6cddf1

I'm quite unsure how to proceed now: Use our own fragment recipes, write
another RFC or try to generalize the approach with the help of a vocabulary.
RFC5147 would then need to be extended by a "type=RFC5147" or
"type=offset" or "type=hash" parameter and you would be able to lookup
what "RFC5147", "offset" or "hash" meant. Could you give us some
suggestions as we do not want to invent the 15th competing standard[7] .

Another problem, we have is that the fragment id is not sent to the
server. Did this ever play a practical role up to now? For Linked Data
it can be cumbersome: Let's say you have a 200 MB text file, with
average 3 annotations per line (200,000 lines, 600,000 triples ).
Somebody attached an annotation on line 20000:
<http://example.com/text.txt#line=20000> my:comment "Please remove this
line. It is so negative!" .
When making a query with RDF/XML Accept Header. You would always need to
retrieve all annotations for all lines.
Then after transferring the 900k triples, the client would throw away
all other triples, except the one for this line.
Currently, we do not care whether we will use "?nif=" or "/" or "#" and
leave this up to the implementer.

The summary got quite long now and below are even more aspects
mentioned. I hope this is not too confusing.
All the best,
Sebastian

[1] http://www.slideshare.net/kurzum/nif-nlp-interchange-format
[2] http://aksw.org/Projects/NIF
[3] http://lod2.eu
[4] http://tools.ietf.org/html/rfc5147
[5] http://tools.ietf.org/html/draft-hausenblas-csv-fragment
[6] http://nlp2rdf.lod2.eu/schema/string/
[7] http://xkcd.com/927/

-------- Original-Nachricht --------
Betreff: Re: Document fragment vocabulary
Weitersenden-Datum: Tue, 16 Aug 2011 06:15:14 +0000
Weitersenden-Von: public-lod< at >w3.org
Datum: Tue, 16 Aug 2011 15:09:21 +0900
Von: Sebastian Hellmann <hellmann< at >informatik.uni-leipzig.de>
An: Michael Hausenblas <michael.hausenblas< at >deri.org>
CC: Michael Martin <martin< at >informatik.uni-leipzig.de>, public-lod
<public-lod< at >w3.org>, Alexander Dutton <alexander.dutton< at >oucs.ox.ac.uk>

Am 16.08.2011 14:12, schrieb Michael Hausenblas:
It does not scale for large documents. Let's say you have a 200 MB text
file, with average 3 annotations per line (200,000 lines, 600,000 triples ).
Somebody attached an annotation on line 20000:

<http://example.com/text.txt#line=20000> my:comment "Please remove this line. It is so negative!" .

When making a query with RDF/XML Accept Header. You would always need to
retrieve all annotations for all lines.
Then after transferring the 200 MB, the client would throw away all
other triples but the one.

Hm, actually you created an extra standard yourself for csv, because the
approach by Wilde and Dürst did not cover your use case.
It does not cover mine either for 100%. Potentially, there are a lot of
text based formats. So there should be a way to extend the pattern somehow.
Wilde and Dürst provide integrity checks, but there is no proposal that
produces robust fragment IDs. e.g. something that works on the context
and not on line or position. A change in the document on position 0
might render all fragment ids obsolete. E.g. "#range=(574,585)" would
not be valid, if one character was inserted at the beginning of the
document.

Ok, thanks for clarifying that.
The # part not being sent to the server might be interesting for this
list as it is a linked data problem. Also I think we should create an
OWL Vocabulary to describe, document and standardize different fragment
identifiers, as Alexander has started. But we should only do it with the
w3c. Otherwise it will truly become "competing standard 15" .
The ontology could also just be descriptive, reflecting the RFCs.
Should we cross-post? Alternatively I could just start another thread there.
Sebastian

uri-templates implementation feedback.

Marc Portier — 2011-08-09T06:50:42

Hi all,

I've finally come round to updating my js implementation to the latest 
state of the spec (that is currently r71 at 
http://code.google.com/p/uri-templates/)

I know this has no official 0.6 label (yet), but since it fixed some 
samples and removed some more requirements (e.g. the 'default') lazy me 
thought this to be an easier goal.

Anyway, here some findings:


[unnamed list expansion for ; matrix-params]
Anyway: I only have one case that made me add some quirk to comply to:
   {;list*}              ;red;green;blue

Without the quirk my implementation produced:
   {;list*}              ;list=red;list=green;list=blue

Well, I obviously don't like quirks, but sentiments aside I am left to 
wonder if the matrix-parameters are not always expected to carry a name?



[encoded names]

If I understood the spec correctly the varspec-names can contain 
pcnt-encoded characters, and should be decoded to translate onto 
context-keys.

Thus the following expansions should work out as listed, right?




[nesting context variables]

The spec doesn't play out dereferencing nested structures by using . (or 
some other notation) between variable-names.

I'm not sure if this on purpose or just a wicked idea from me:


Dunno if this makes sense to add, but it seems like a fairly easy thing 
to add in the implementation.

On the other hand, it can be overcome by preprocessing the context 
structure (pretty much similar to how we currently would be adding the 
removed 'defaults' behavior, no?)

Note there is a challenge to correctly define 'preference of finding' 
which of possibly multiple matching keys with this approach. "a.b.c" 
might be found at any of: "a.b.c" "a"->"b.c", "a"->"b"->"c", "a.b"->"c"



All for now.
My implementation can be found at 
https://github.com/marc-portier/uri-templates  (The two failing tests 
(src/test/webenv/test.html) at the moment are the ones mentioned just 
above, I'll gladly fix taking into account your responses and 
clarifications.  If time permits I'll try to add some more edge-case tests)


regards,
-marc=

uri templates: NFKC or NFC

Roy T. Fielding — 2011-07-14T23:31:51

The URI Templates draft currently requires use of the NFKC for
normalization of Unicode strings.  I've never understood why
that is, considering that IRI does no require it and
browsers appear to use NFC (if anything).  Also, it should only
apply to the expansions -- the literal parts don't need to be
normalized.

Should I change it to NFC?

....Roy

Definition of blob URI Scheme

Philippe Le Hegaret — 2011-06-21T19:01:26

Hi Mark,

I'd like to check with you my understanding of RFC 4395 [1].

The FIle API specification contains the definition of the blob URI
scheme [2]. Following the registration procedure, my understanding is
that:
1- Arun should reformat section 6.7.1 [2] (or include a new section) to
follow the template at [3];
2- Once our specification is in LC, Arun should send an email to
uri-review< at >ietf.org asking for review (and address whatever comments
come out of that);
3- At CR, Arun should request registration from IANA (iana< at >iana.org),
asking for provisional status;
4- At PR (or REC?), Arun should request permanent status from IANA.

Do you concur with those steps?

Philippe

[1] http://tools.ietf.org/html/rfc4395#page-9
[2] http://dev.w3.org/2006/webapi/FileAPI/#ABNFForBlob
[3] http://tools.ietf.org/html/rfc4395#section-5.4

Fwd: Last Call for HTML5 in the W3C

Mykyta Yevstifeyev — 2011-06-18T04:49:01

Hello all,

17.06.2011 23:46, Mark Nottingham wrote:
This document, especially Section 2.6 and some other URI-related stuff, 
may be interesting for people on this list.  Please provide your 
comments to apps-discuss list, preferably copied to Mark Nottingham, who 
is the IETF/W3C liaison.

Thanks,
Mykyta Yevstifeyev

Discussion of Blob URI Scheme for Binary Data Access | IETF

Arun Ranganathan — 2011-05-13T18:05:39

Greetings URI listserv!

I'm writing to this listserv at the behest of Mark Nottingham, who sent 
me here from the ietf-http-wg< at >w3.org listserv. This email is about a 
"new" URI scheme used to access binary data, and we'd like feedback on 
it, as well as advice on whether any further standardization endeavors 
are necessary.

My name is Arun Ranganathan, and I'm the current editor of the File API 
[1] specification (sometimes called the HTML5 File API, which is 
unfortunate); I'm also the former Chair of the WebGL Working Group [2] 
(which brings hardware-accelerated 3D graphics to the web), and have a 
continued interest in allowing binary data to be securely accessed and 
manipulated on the web.  I'm sponsored by Mozilla.

The File API introduces the notion of a Blob object [3], which 
represents immutable binary data.  A file from the underlying file 
system can be asynchronously read as a Blob object into various data 
formats, for example.  The existing File interface in JavaScript 
inherits from Blob.

Additionally, and most significantly for this listserv and this 
discussion, the File API introduces a URI scheme for Blob access [4].  
The URI scheme uses a subset of the HTTP status codes, and is designed 
to be used wherever http URIs can be used within HTML markup and within 
APIs in JavaScript (e.g. for "img src =", alongside XMLHttpRequest, 
etc.).  The nascent URL API [5] which coins and revokes blob: URIs is 
also used with the Stream API [6] for video-conferencing use cases, and 
thus this scheme is becoming integral to emerging technologies under the 
broad aegis of HTML.

Browsers such as Chrome already implement blob: URIs [7]; Firefox's 
implementation will follow-suit, although is likely to be 
vendor-prefixed.  Our goals are to address the shortcomings of the 
file:/// URI scheme, which many browsers support for directory browsing 
of the underlying file system, but for little else (file:/// URIs are 
unwise choices for APIs like XMLHttpRequest, don't supply response 
codes, etc.).  The blob: scheme was designed to address the use case of 
dereferencing files and binary data on the web safely, since data: URIs 
have shortcomings as well, and can't really be used for streams of data.

We'd welcome your feedback, including suggestions about whether 
embarking upon an IETF standardization track for this protocol is 
necessary.  The File API will soon be initiating a CFC for Last Call status.

uri-templates 0.4 javascript implementation feedback

Marc Portier — 2011-04-28T07:17:25

Hi all,

Finally got round at this javascript implementation of
http://tools.ietf.org/html/draft-gregorio-uritemplate-04

(minus the partial syntax and some more testing)


Anyway, it is open at:
https://github.com/marc-portier/uri-templates

It wraps inside JQuery and comes with tests up in QUnit.
(JQuery dependency currently limited to the handy $.extend and $.isFunction)


Must say getting my head around things asked more time then I initially 
expected: clarity and elegance of the syntax and explanation did hide 
quite some more special cases then I would of have thought of.

One case I still haven't ironed out, to the extend I'm liking my 
solution more :) is this:


which in my mind (and implementation) follows more closely the line of 
thinking in:


the consistency I see is this: both ; and ? operators deal with named 
parameters, in unexploded form the values are wrapped up in one string, 
but still expect value.


best regards,

-marc=
PS: The link to the promised js implementation from 
http://code.google.com/p/uri-templates/wiki/Implementations points to 
some reserved space at www.snellspace.com  (I remember grabbing a 0.3 
implmentation from James' blog way back, that is somewhat maintained 
over here: )

uri-templates 0.4 javascript implementation feedback

Marc Portier — 2011-04-28T07:34:28

Hi all,

Finally got round at this javascript implementation of
http://tools.ietf.org/html/draft-gregorio-uritemplate-04

(minus the partial syntax and some more testing)


Anyway, it is open at:
https://github.com/marc-portier/uri-templates

It wraps inside JQuery and comes with tests up in QUnit.
(JQuery dependency currently limited to the handy $.extend and $.isFunction)


Must say getting my head around things asked more time then I initially 
expected: clarity and elegance of the syntax and explanation did hide 
quite some more special cases then I would of have thought of.

One case I still haven't ironed out, to the extend I'm liking my 
solution more :) is this:


which in my mind (and implementation) follows more closely the line of 
thinking in:


the consistency I see is this: both ; and ? operators deal with named 
parameters, in unexploded form the values are wrapped up in one string, 
but still expect value.


best regards,

-marc=
PS: The link to the promised js implementation from 
http://code.google.com/p/uri-templates/wiki/Implementations points to 
some reserved space at www.snellspace.com  (I remember grabbing a 0.3 
implmentation from James' blog way back, that is somewhat maintained 
over here: )