On 12/30/06, Thilo Goetz <[EMAIL PROTECTED]> wrote:
> Why use the bandwidth to design it here, rather than initiate it at
> OASIS?
<snip>
Because things are happening here, and not at OASIS. If and when that
changes, we can take our discussion there. If you would like to start
some discussion at OASIS, feel free.
I already did, by writing the meat of the spec proposal whitepaper.
I'm waiting for another party so it won't be a discussion of one.
You're right, here we have fully twice as many people participating in
the dicussion! :) Anyway I still think discussing the right things in
the right places will be important to do. I guess it will fall on me
to make that happen.
> (1) The XMI serialization could contain objects that are not in any
> view, nor referenced from anywhere. Our implementation doesn't
> support that. We'd lose such objects on a deserialization followed by
> serialization, and even if we didn't lose them, not providing any APIs
> to access them seems poor.
I don't see that we would loose such objects. You just define an index
over all objects and there you are. That also gives you an API to
access them. And no, we should not provide such an index by default.
Many, if not most, applications won't need it.
Are you using "define an index" in the same sense as we currently do,
where someone has to call addToIndexes for something to be indexed?
Or is this a new kind of index that contains everything no matter
what? I think it would have to be the latter in order to support this
using the current XMI serialization format (which has no concept of
index membership separate from view membership). Is that what you
intended?
> (2) If we decided to add some kind of global indexes to our
> implementation (as was being recently discussed), that has no
> representation in the XMI serialization. This seems like a problem to
> me. How can we add things to our implementaiton that are supposed to
> be persistent across CAS serialization without opening up a discussion
> of what the serialization format looks like?
I didn't look at the details of the XMI proposal because frankly, I'm
not very interested in XML serialization. The conceptual part of the
report does not contradict that approach, at least the way I read it. I
probably missed something. Where does it say you can't have global
indexes (or the OASIS equivalent thereof)?
The OASIS spec proposal only defines views. In our implementation we
define indexes and say that we have an index repository per view and
that the members of the view are indexed in that index repository. If
a "global index" means an index containing objects that are in no
view, then this approach no longer works.
I really think the XMI serialization is a key intersection point
between what we're doing in our CAS implementation and what OASIS is
charged with doing. Each group looks at the XMI serialization in a
different way - for us developers, we may just want to throw in new
attributes or whatever to make our latest, greatest implementation
idea work. The people in the OASIS group (at least some of them) look
at it as a realization of basic UIMA concepts. That may sometimes
become an annoyance for us, since we might like to shape the XMI
serialization however we want, but I think ultimately it's a good
thing for UIMA.
In the case of global indexes the issue with XMI serialization is that
there's no way to mark an object as being indexed without marking it
as being a member of a view. Now, I suppose we could just define a
special view named "global" and be done with it. But then, our APIs
would (should) be different than if we have special global indexes
that "belong to no view".
-Adam
