can/should we extend simpleURL endpoint handling to user input?

[balmas]

One of the features we lost when switching to Capitains Sparrow for the CTS selector on the Perseids treebank editor was the ability for the user to supply a URL at which to retrieve TEI (or plain) text. This is partially handled by the support for a "text_uri" param and the checkURI function in the in the jquery.cts.typeahead selector, but not entirely. That only works with params that are passed in in the query string, so it won't work with user initiated form input.

Although I could work around this in a number of awful ways, it seems like maybe we should try to do this right, which might mean taking this out of here, I'm not sure. This is also related to #5.

As I see it the two main user stories driving this are the following:

1. as an application I want to be able to identify a URL at which to retrieve text (XML or plain) for processing in a client side workflow and pass this to a form which embeds these workflow components so that the text can be automatically processed.
2. as a user of a form which embeds these workflow components, I want to be able to specify a URL at which to retrieve text (XML or plain) so that the text can be processed

And, we might also consider the following (which is the subject of #5)

1. as an administrator, I want to be able to specify a uri prefix for my CTS URNs, to turn them into resolvable URLs.

The implication of the last one for Capitains Sparrow is a bit unclear to me still, because when we are using a CTS endpoint as it exists today (i.e. and not some truly RESTful replacement), the URI prefix is just a decorator to the URN for purposes of these components.

[PonteIneptique]

So, I am not fully sure to understand what you require. But here is what I understand, and my feeling about it :

• You want to be able to use simpleURI endpoint in Capitains-Sparrow typeahead selector.
• You want to be able to convert an edition/a translation into another kind of URI.

Technically, this is already possible because of endpoint implementation. I don't think the issue lies in Capitains Typeahead but in the implementation of treebank. There should be an input form in the treebank app to give an URI which would be then converted to a text object.
For the second thing, I think it should lie in the callback function you implement. But all of what you require is possible and I think should not lie in the Typeahead. The typeahead functions should be only focused on: browsing a text inventory efficiently. The text_uri is I think regarding my latest statement something that should not lie in there, but we can keep it.

Did I understand you well ?