OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

regrep message

[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