[ome-devel] More details on "Locked" attribute please?

[Isaak Berg]

>> Could someone please provide a use-case scenario of how the "Locked"
attribute is intended to be used?

>Locked simply means that the Dataset's collection of images can no longer
be altered.  This is the case when Dataset-granularity
> attributes are generated for the dataset.  For example, one could perform
a calculation over all of the images in a dataset (average
> signal intensity, say).  If the set of images comprising the dataset is
subsequently altered, then the computed signal intensity
> would no longer be valid.  So the Locked attribute is used to signify that
there exists a piece of information pertaining to the dataset as a
> whole.

Then it seems to apply mostly in the context of the semantic types version
of OME-XML obtained from the ome.xsd style XML via XSLT? Is this the schema
by which most OME- files are expected to be found floating around
cyberspace? 

Is there any assumption or design idea favoring the base ome.xsd style or
the STD.xsd style OME-XML/TIFF data as the preferred format for general
interchange, or should readers be expected to read either?

This clearly makes sense within files or a database where exclusively one
OME-aware application has access, but I am struggling with this concept a
bit because for example I don't know how it will or even ought be treated if
say an OME user creates or retrieves from some database some OME files and
then e-mails them to say, some other OME user on the other side of the
Atlantic Ocean.  It doesn't seem secure or general enough to justify
full-blown prevention of writing over the data merely because the locked
attribute had been set some time in the past by some application or some
database, but could certainly justify not allowing overwriting the pixel
data without generating a new Pixels ID. 

What about the case of multiple file distribution (at least for OME-TIFF, I
can't remember if OME-XML talks about this)?
What if several files reference the same dataset, (or even the same pixel
set), but later (whether a few hours, or a few days, or years) after they
are generated, another user opens only one or some of them, and sets the
locked attribute.
Say this file gets submitted to a database with Locked = TRUE before the
other files of the same dataset (in separate actions) with Locked = FALSE?
Is there any rule or tool or convention or general practice to prevent that
situation, or to deal with it when it arises? 

Are there any further details on who or what application is responsible for
setting the locked attribute? Should proprietary software designed to import
from and export to OME-TIFF format give special treatment of Locked = true?
Either way, more details please. Surely this attribute must solve someone's
problem(s).  but whose and what problem(s)? Even understanding that, would
help greatly in deciding how to treat this attribute.
This sort of seems like really an internal value that should really be
handled differently (whether that means removal or set to true or whatever)
when sending data cross-application? If so, wouldn't it be better to have
some consensus before dozens of different OME-capable applications get
compiled and distributed, each with a possibly different rule about this
attribute?