<Olof> In the examples in the specification document <targetSource> is in some cases identified by "xml:id" and also a "source" on page 7. Is there a reason for having a temporary id as an xml:id and not the whole uri+fragment in the relation reference?. For the client it´s important to know where to look for the URI to be able to get the fragment containing the start/end for the annotation.

<Twan> I think indeed this could be solved without the xml:id; the source URI should already be a unique ID.

<Menzo> Yes, and if the relation body is serialized in RDF it has to be URIs instead of IDs.

<Olof> I think we need to establish an XSD schema as soon as possible for the representation of the serialized objects and a few close to real life examples. This will be a good exercise for finalizing the exchange format, for finding other issues and ideas for future improvements.

<Twan> Yes, I agree. Is this something we were going to do?

<Menzo> Yes, I think the plan was that we would create more XML examples including schemas. We didn't decide on a schema language ... unfortunately XSD is still the prevalent one ;-)

<Olof> In the example (page 3) identification of the annotated node (start/end) is made by using xpointer (fid), Wired-Marker uses hyperanchor <​http://www.hyper-anchor.org/en/technical_format.html> and it works in a somewhat different way. Hyperanchor allows storage of color etc. and requires less work effort and no changes in Wired-Marker. Is xpointer important for identifying the annotation, and if so is conversion from hyperanchor to xpointer required for the client?

<Twan> I haven't looked into hyper anchor but I don't see why xpointer would be a hard requirement as long as it does the job of reliably referencing a fragment. I'm a bit worried about storing properties of the annotation (such as colour) in the fragment identifier though.

<Menzo> I agree storing (some of) the annotation info in the fragment identifier would be wrong. The fragments identifier should only contain information to pinpoint a specific fragments in a source, not additional rendering or annotation info.

I don't know hyper anchor. In principle I would go for a standard where possible, e.g., XPointer or one of the W3C recommended media fragments. Also because WiredMarker? is only one of the tools that could do something with the annotations, i.e., when possible don't bind it too tight to WiredMarker? but keep it generic. But I guess this can only be a guideline, annotation bodies and cached representations could be tool specific, also there will be very specific fragments (LEXUS lexical entries, ELAN annotations; but those might still be referenced with a standard fragment identifier (Xpointer?)).

<Olof> When retrieving more than one source or annotation we need an wrapper, this should be specified in the REST-specification. For ease this wrapper should always be used, even if the result is one object. This wrapper should also contain information about the total amount of objects if it is larger than the pre-defined maximum of objects returned. This is important for the specified paging e.g. "GET api/sources?uri=<aoid>&maxSources=<number>" on page 14. We also suggest to replace the maxSources with a more general parameter (e.g. "max") that can even be used for limiting the maximum amount of annotations returned. Furthermore, we need a param for start to be able to get the next set of objects. E.g.: <result start="0" max="10" total="42"> ... </result>

<Twan> I think this is fine as well, I would propose to add it to the API specifications like this.

<Menzo> Sounds good :-)