[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: Regrep 2 Mar meeting minutes
OASIS Regrep TC Meeting 1-5 P.M., 2 March 00, San Jose Minutes Attending in person: Nagwa Abdelghfour, Sun Terry Allen, Commerce One, chairman Una Kearns (toward the end of the meeting) Priscilla Walmsley, XMLSolutions Yutaka Yoshida, Sun Attending by phone: Lisa Carnahan, NIST Robin Cover, ISOGEN Attending as visitors: Megan MacMillan, Solista Christina Portillo, Boeing The chairman called the meeting to order shortly after 1 P.M., and reported that the Advisory Committee on Technical Committees had met and voted to reinitialize the Regrep TC as requested; thus this is the first meeting formally conducted under Robert's. Terry volunteered to take minutes. There was discussion of EBXML and what some of the various project teams were doing. Christina, who is following Regrep for Boeing in lieu of another Boeing employee who will join soon, reported that Boeing is setting up a data sharing and interchange baseline describing architectural elements needed to support interchange of data: packaging, content object, associated metadata, storage, registries, mechanisms to request data, and more. Lisa reported that NIST is almost done building hash tables to database structures, and will start on putting data into the database soon. In about 3 weeks they'll be ready to start loading data. They need test data, which we hope will be supplied by XML.org. Terry reported that XML.org is still organizing itself. Nagwa noted that Sun and Documentum have started on implementation but are still waiting on XML.org to agree formally to accept the S+D proposal. There was discussion of interoperability and on what level it works. Some folks would like a consistent interface for submission across all registries; this is something not currently in the spec. Christina felt there was a need to have service profiles for other registries to support interoperability in querying and access to their contents; this is something we've put off for a second phase but need to bear in mind. A variety of items came up for discussion: Lisa agreed to suggest conformance language for the OASIS spec. Terry promised to include 11179 definitions of RA, SO, RO in the spec. It was pointed out that multilingual requirements have not yet been considered. We talked about how to handle multiple formats of "the same" thing, without definite conclusion. In the current spec, there would be no two versions of the same thing, because format is 11179's "representation". Their relationship would be declared as part of noting that they are related data (reciprocally). See dbrelated.txt in the current distribution. A related issue arose: how do we manage approval of a submission composed of multiple parts? Nagwa would like to be able to deal with the whole set of parts together. Lisa explained her set of suggested revisions to the spec and its language, which Terry agreed to make. It was asked how we can deal with extensions to metadata (which we have completely ignored so far). Terry agreed to write up the issues for discussion in email. Lisa points out that IMS already has extensions. Terry moved that we agree to meet according to the current schedule (by phone every other week and in Paris on 15 June, 1-5 P.M.). The motion passed without objection. Una arrived at 3.45, and discussion turned to issues raised by initial implementation design. We haven't described fully interoperability. What are the "touch points"? Una suggests: register to be an SO submission what's in a submission what does it mean to update a submission what is process for workflow within a registry? (it's a black box) how is content served? [Note the desire for interoperability in the submission process again.] After some explanation from multiple viewpoints, it became clear [Terry thinks] that Una wants any given submission to have the same metadata for all the parts, except for the specification of relationships among related data, and would even like some parts of a submission not to have to have metadata other than the note that they're related to the main piece of the submission. Terry realized that the Docbook example in the current spec doesn't show metadata records for all the related data, and that it should. Lisa made a distinction between related and associated data. Do we really want to have records for all this stuff? To be discussed in email. Una wants a level we haven't specified, which is the group of all related data; this may correspond to a node in a taxonomy of classified registered objects; it does not necessarily correspond to the contents of a given submission. Terry will work on this issue with Una. For example, Una wants the registration metadata to be given once for an entire submission package, and combined with a manifest of all the pieces of the submission. The meeting adjourned at 5 P.M. as agreed. (Terry)
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC