11 Nov F2F notes

[Terry Allen <tallen@sonic.net>]

N.B.:  conf call Fri AM will be held as planned.

OASIS Regrep TC Face to Face
11 November 1999
Agenda

 - discuss agenda, new items
 - review DTDs in detail
 - review revised THTTP
 - examine the implications of the registry interface for the work
	we've done so far
 - work out or review how to do a full (including compound) data element 
	description in the 11179 DTD
 - reminder of next face-to-face, in Philadelphia
 - THTTP
 - new items
 - adjourn

attending:

Joe Alfonso, Sun
Terry Allen, Commerce One
Markus Breilmann, Tamalpais Group
Bruce Peat, eProcess Solutions

We had a good meeting, but adjourned after lunch as we were falling
below critical mass.  We won't meet on the 12th.  We focussed on
DTD review, and identified changes to make to the DTDs and additions
to be made to the examples.  Below are summary notes (we did
discuss THTTP, but not the items below it; Terry has agreed to
revise the relevant RFC but hasn't done it yet).

11 Nov 99, morning

Add to agenda:  what about the socat?  (see below)

registry.dtd isn't used by any example; it is just to show that
you can represent the contents of a repository per 11179 in a DTD.

class.dtd lacks administrative metadata, though it should have it,
and the DTD needs to allow identifiers (from common.ent) on items 
so you can use them if you want (though you should be able to point 
into a classification scheme without them).

You might want to show in the interface how many items are under
each taxon, and how many subscribers there are for it.

We probably should add a data-element-dictionary-set element to 
eliminate the need for administrative metadata on each 
data-element-dictionary (as in the present examples for Docbook).

db7, you would want to use the "uses" relationship (for the CALS
table model module) to generate the information necessary for notifying
the owners of Docbook when that CALS module changes.  (In real life
this won't be necessary for this particular case, but in the general
case it might be useful.)

db7, the Identifier used on the data-element-dictionary element
is kinda bogus and isn't paralleled in db1-6.  To fix.

For specifying date format, find one (the W3C profile?); Joe suggests 
dates should be attributes rather than PCDATA.

"book" in db1.txt refers to a classification scheme that has not been 
defined (oops).

classified-item-description isn't used in an example, but
should be, and maybe needs substructure (paragraphs, for example).

It's kinda dangerous to allow submittors to extend a taxonomy;
that needs careful consideration.  (We spent some time on this one;
the problem shouldn't arise soon for XML.org's repository, but may
after some time.)

data-element-association-list should be used re db1.txt.

In the specification, explain the difference between db1.txt and db7.txt.

Joe:  currently there is no difference between saying that docbook.dtd
"uses" other Docbook modules and that the whole thing "uses" CALS  - 
extend the example and distinguish between "uses" within a set of
modules all of which are developed and distributed by the same SO
and modules from elsewhere. 

Extract the documentation presently in comments from the DTDs and
present it separately to make the DTDs cleaner to read.

Terry, why do you have related-data-group and its alternate in
the data-element-content entity?  Terry to reflect on this and
document the purpose.

Eliminate the %uri-reference; parameter entity, which is vestigial.

Use some keyword-sets to illustrate usage and intent.

There's a confusion between data-element-reference, which refers to 
some else in the format of this DTD, and data-element-dictionary-reference, 
which can point to something in some other format (e.g., the Docbook
modules themselves).

Change the language attribute to xml:lang.

Info in the data-element-dictionary should be identified as to whether
it comes from the SO or the RA (probably by means of attributes on
each, or at least the relevant, elements - note the implied requirement that
such info be elements rather than attributes).

Note to Angela Chen, who will be working on the initial XML.org
implementation:  one wants to arrange the submission interface
so as to prevent the SO from providing info only the RA should
(if possible).

Consider omitting object-class and property, which don't seem to
work too well for the purpose of describing DTDs and schema, but
are integral to the 11179 view of things, and write up something
for the list about the issue (Terry's item).

Is there in fact an object class for a DTD, e.g., the one for
which db1.txt is the metadata?

Review the utility of representation in this connection, and
justify.

Add format info to related-data-reference (if it's documentation,
is it in XML, PDF, or what?).

In urnresprefs.dtd, what is the processing expectation of specifying
a file as the resolver; would you make an THTTP request to a file?
should this be a socat?


regards, Terry

Terry Allen                             
Advanced Technology Group               
Commerce One, Inc.
Walnut Creek, Calif.
tallen[at]sonic.net