Re: [ACTION-256]: Compile and circulate itsTool examples togehter with proposal text

Hi Felix,
Yes, the URI pointer work in most cases, but this is to address the case 
where we want to embed the target of the pointer in the file (based on 
the case linguaserv brought up in Lyon, where they may be able to ammend 
file but can add new ones to a client's CMS, so it problematic to 
mandate an external file only) and it is HTML file, so a simple element 
fragment URI won't work.

We are also, I guess, trying to make the solution a similar as possible 
to the stand-off markup case to ease implementation.

cheers,
Dave




On 07/11/2012 11:26, Felix Sasaki wrote:
> Hi Dave, all,
>
> apologies, I'm behind things. I thought we'd agreed at the f2f meeting 
> that there is just an URI pointing to tool information, nothing else. See
> http://www.w3.org/2012/11/02-mlw-lt-minutes.html
>
> [
>
> Felix: You could have a seperate script element for each standoff item.
>
> … pitty Yves cannot be on the phone. He has raised concerns: anything 
> possible, tool with element it in, or define a schema. There is a 
> drawback that you restrict people to xml processing, what about the 
> case of RDF or audio. Does everyone who needs the element need XML?
>
> ...
>
> <fsasaki> "Disambiguation|file:///tools.xml#T2" > 
> "Disambiguation|http://enrycher.com/v1.2/language-en"
>
> Felix: Paste proposal into chat, from Yves, this URI itself is just a 
> URI, no further information, self-contained in the URL. This tool is 
> X, in Lang Y, in the URL where each tool can create the tool itself. 
> But in a large document this is the list of annotation with URI = 
> tool1, URI = tool2. Dont restrict the URI being retrieved and XML 
> removes this restriction.
>
> Dave Lewis: Naoto has interest in this.
>
> … any other comments else I'll take this on board, update text, get 
> feedback from Tadej and Yves. Try to update and send off today (2nd Nov).
>
> Tadej: I like felix's suggestion on URI encoding. All people will not 
> be able to encode in a common format but good to provide best-practices.
> ]
>
> So why do we discuss the toolinfo element and id resolution in 
> "script" at all?
>
> Sorry for the additional loop,
>
> Felix
>
> 2012/11/7 Dave Lewis <dave.lewis@cs.tcd.ie <mailto:dave.lewis@cs.tcd.ie>>
>
>     Hi Jirka,
>     Thanks for that.
>
>     So to check, does the solution suggested by Yves, i.e. reflecting
>     the toolInfo id in the script id,
>     http://lists.w3.org/Archives/Public/public-multilingualweb-lt/2012Nov/0019.html
>     and only having one toolInfo element per script as discussed in.
>     http://lists.w3.org/Archives/Public/public-multilingualweb-lt/2012Nov/0038.html
>     solve this problem?
>
>     cheers,
>     Dave
>
>
>     On 05/11/2012 15:59, Jirka Kosek wrote:
>
>         On 2.11.2012 14:29, Dave Lewis wrote:
>
>             For HTML this works when the tool info is external to the
>             file. However,
>             it doesn't work when the tool information is held with the
>             file. Here we
>             could use the XML in htm:script element solution that we
>             use for mark-up
>             in some of the data categories (e.g. Quality Issue). In
>             this case we
>             would need to specify in the spec the element type the IRI
>             refers to.
>
>             So we would need the following wording:
>             "Where the IRI in not used in a its:toolRefs attribute in
>             an XML
>             document or not for pointing to an external resource in a
>             its-tool-refs
>             attributed in a HTML document, then it MUST refer to a
>             its:toolInfo
>             element."
>
>         This is not technically possible. In HTML its:toolInfo inside
>         <script>
>         element and is not exposed as a markup, it's just plain text
>         inside
>         <script> which doesn't have ID and can't be directly addressed.
>
>                                 Jirka
>
>
>
>
>
>
> -- 
> Felix Sasaki
> DFKI / W3C Fellow
>