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: 24 March conf call minutes

OASIS Regrep TC Conference Call
Friday 24 March 2000


Terry Allen (chair)
Lisa Carnahan, NIST
Robin Cover, ISOGEN
Yutaka Yoshida, Sun
Norbert Mikula, DataChannel
Nagwa Abdelghfour, Sun
Una Kearns, Documentum

Attending as visitors:

Ron Daniel, MetaCode
Ernie Nishiseki, Dun & Bradstreet
Jamie Walker, Boeing

NIST is still coding, will have comments on outstanding issues

EBXML-Regrep, in its conference call, discussed deliverables for
the Brussels meeting and the suitability of UML as a modelling

XML.org is going ahead on their implementation; there is
continued unclarity about the difference between related 
and associated data.  Lisa promised to write something up
on the NIST approach (N.B. this was subsequently clarified
in email; association are between data elements and composites;
related data is documentation and the like).

URNs:  Ron suggests that we reuse URN name spaces as much as possible.
GUIDs are okay, too; however, it's cleaner all round if GUIDs are
expressed as URNs.  Microsoft is the author of the GUID spec;
Ron will try to dig up an old GUID URN draft.

Review of open questions re email of 11 March:
 Sat Mar 11 15:15  77/3258  "eliminate regrep subm"

Terry proposes saving the doctypes and not the packaging method;
Lisa  proposes leaving it open; we agree on saving the
semantics but they need more work. Terry to make a proposal.

Extensions:  Terry proposes that instead of kitting out the
DTDs to support extensions, extended versions of the specified
metadata be served as responses to the I2C request, and that
(telescoping some discussion) we *do* specify an I2X request
that will always return the metadata record specified by 
OASIS (with contact data suppressed if appropriate, to avoid
spam).  Ron points out you can add a link to "more info if
desired", which, if traversed, can lead to a check of

 Sat Mar 11 15:45  71/3230 "individuals as SOs?"

We agree that individuals who act as contacts should identify
as their SO the largest unit that can coordinate internally.
Multiple contacts may be desirable (if they can coordinate),
and it should be possible to identify the parent org of the
unit (although this can get exceedingly messy, we can handle
the simple case). 

Should we allow multiple contacts per org?  NIST's design
allows that, but only one would be active at one time.
We should add the possibility; it will be up to business
rules how this information is employed.

 Sat Mar 11 15:45  70/2300 "implementors:  types "

No additional types of related data were identified.

 Sat Mar 11 17:00 166/7977  "the simple case and t" 

Much discussion.  Terry and others are of the view that 
if something is registered it must have its own metadata
and be a first-class object.  Lisa observes that IMS is 
flat and doesn't have registered related data.  The issue
of whether to allow related data references to data that
isn't registered anywhere remains open.

Lisa also remarks that at a recent NIST-hosted conference
she encountered AIIM (document imaging group) and NISO, 
which are both working on registry specs.  Laura says 
AIIM and OASIS have made contact.

NISO - National Information Standards Organization; Terry
will check it out.

regards, Terry

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]

Powered by eList eXpress LLC