Slicer3:UIDesign:WorkingProblems:SlicerInformatics:Draft1

Discussion at the NA-MIC 2009 AHM in Salt Lake City

Planning XNAT and Slicer integration next steps

Rough timeline for the next several months

Discussion points and action items

Deleting:

• resources (Use http delete),
• tags on resources, and
• tags from whole repository

Kevin will email wendy the API for the last two of these.

QA: detecting whether uploaded data is valid. WUSTL is thinking about QA; right now no provision. Future, maybe look at checksum on server side... Maybe there's a short-term soln: API provision for client to query for remote file size, and check this against local file size, the request file be deleted on remote host if no match...

Server ID: is there a way to validate a server as XND? We want to expose capability to 'add a new server', and a way to query the resulting servername for its identity, like

 http://xnd.slicer.org:8000/identify

Kevin will look into this and update Wendy.

Security: no security yet. A first pass will come soon, probably http basic.

Tag/value length limits: There are no intentional limits on tag/value lengths. Long names and values may slow search time.

Special character restrictions: excaping all characters as for xml/html should be sufficient.

Note: WUSTL implemented a file browser metaphor for looking at hierarchy of resources, found that intuitive for users.

Note: XND current version is challenged by enormous datasets (like large collections of DICOM). Fix to this coming in version 0.8, with "collection support".

Note: Current XND version 0.7 is compatible with Slicer's existing implementation. Slicer will have to be modified to take advantage of Version 0.8's collection support: collections may not be supported by XND FileServer until a month or two after XND 0.8 is released. Misha will let Wendy know when draft API is available and advise.

Format tag: In the event that URIs don't contain an explicit extension (like those for XNAT-E, which also encode ticket info) we need some kind of tag on the dataset that Slicer can use to know how to open/load it. Current Slicer implementation automatically generates a "SlicerDataType" tag that it uses for that purpose. Better if we change that logic to use a "Format" tag that Slicer- and non-Slicer-people use. But we need to encourage the value assignments to be somewhat consistent. Can we create an XND default tag with a pre-populated set of values that takes a good stab at this? If so, Slicer can be modified to use "Format" instead of (or in addition to) "SlicerDataType".

Annotations, Thumbnails, and other derived data: We discussed the best way to accommodate annotations, and other data (thumbnails) associated with a particular dataset or collection of datasets. We would want to be able to:

• create these 'documents or datasets',
• upload them and associate them with a resource,
• query for them, and
• download them separately or bundled with data.

FetchMI release into nightly builds: This will happen soon after bug fixing and testing. Wendy will update XNAT team when module is released.