On 12/29/06, Thilo Goetz <[EMAIL PROTECTED]> wrote:
I didn't mean ignore; there isn't much to ignore right now ;-) I'm waiting to jump on any technical discussion that might develop there, but there is nothing. I don't have the bandwidth to initiate anything myself. However, I'm certainly prepared to sell anything to the OASIS TC that we develop here.
Why use the bandwidth to design it here, rather than initiate it at OASIS? For things that don't overlap with OASIS, that's OK. But for things that do overlap, we have a choice as to how to proceed. Figuring out how to do that is what I'm trying to explore. We need to form some kind of working relationship that makes sense here. Merely trying to sell what we've implemented doesn't seem like a strategy that will be effective in all cases. (When I said that originally, I said we should be confident that we *can* successfully sell it, not just that we would try. And that probably only can be the case for fairly obvious things.)
The Research report talks mostly about XMI serialization. If that is all the standard will amount to, we have a pretty free hand with our APIs, as long as we can produce and digest the XMI format.
Yes, that's right. The spec is concerned with the basic structure of the CAS, which is visible when you look at its XMI serialization. So yes, any APIs should be fine as long as we support the basic structure that's embodied in the XMI.
I've been rereading what the report says about views. Basically all it says is that a view is a set of FSs. Or to be more precise: "By members we mean as defined above, those Objects directed asserted to be in the View not necessarily Objects that may be in the Views reference closure and not in the View" (p. 39, footnote 5; had to type as content of report is not copyable). I won't pretend I understand what that means, but under most reasonable interpretations, we are not very much constrained as to how we structure our APIs to be consistent with this.
The genesis of views was to be consistent with what we're doing with indexes. So adding objects to our indexes is supposed to be interpreted that the objects were "directly asserted to be in the view". But consider the following things which aren't quite in sync: (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. (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?
So again, I'm not advocating we ignore the OASIS TC. All I'm saying is that next to no work has happened on OASIS yet. The Research report was written pre-OASIS, as we all know. We shouldn't go off in a direction that totally contradicts the report, but I see no danger of that. I think we can straighten out some of our APIs surrounding views and sofas without being too much concerned with OASIS at this point.
I see the two things I said above as being dangers/concerns that are related to OASIS. -Adam
