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: RE: XML.org implementation (Packages)

Hi Terry, Norm

Is there any chance one of you could send me Docbook and related information
per Reggrep--- I would like to test registering this and its vary
information to see what works does not.


-----Original Message-----
From: Terry Allen [mailto:tallen@sonic.net]
Sent: Wednesday, April 05, 2000 5:23 PM
To: regrep@lists.oasis-open.org
Subject: Re: XML.org implementation (Packages)

Len wrote:
| At 04:02 PM 4/4/00 , Terry wrote in response to Len:
| >| A request to retrieve item DED1 will return only items A and B.
| >| 
| >| A request to retrieve item DED2 will return only items C, D, and E.
| >
| >Items DED1 and DED2 (A,B) and (C-E) are not registered items, so
| >you'd never request their retrieval.
| This may be a big part of my confusion. Since a "submission" is not
| defined in the OASIS specification, I'm assuming that it can only be one
| the following:
|   1)  A single <data-element>
| or
|   2)  A single <data-element-dictionary>
| or possibly
|   3)  A single <classification-scheme>

In discussion it's become clear that a submission could contain
anything, any set of data elements, d.e.d.s, c-s's, or related data.
That appears to be inconvenient without some further conceptual

The spec doesn't try to limit what can be in a submission package
to the list above, and in fact in the revision I'm removing the
zip format (see my earlier suggested langauge) and as much of
the rest of the stuff about submission as possible.  It doesn't
appear to be an API we can define at this point.

| I don't see anything in the spec that would allow submission of a set of
| <data-element>s that are not contained in a <data-element-dictionary>.  So
| in the above example, DED1 and DED2 would be registered items.

This is exactly the confusion:  submission is one process, registering
the contents of a submission is another.  We need to avoid trapping
implementors into having to make submission packages = d.e.d.s (even if 
they choose to require that they be such). 

| Of course we can easily fix this misunderstanding by defining a Submission
| DTD something like the following (using BNF instead of XML to describe
| <submission> ::= 
|    <lead-in-stuff>
|    <submission-content>
| <submission-content> ::=
|   {   <data-element>
|     | <data-element-dictionary>
|     | <classification-scheme> }+
| Then a SO could submit a set of n <data-elements> for registration and
| just the n items registered.  Or, the SO could combine the n
| <data-element>s into a <data-element-dictionary>, resulting in n+1 items
| being registered, the n <data-element>s and their containing "package",
| <data-element-dictionary>. This would give the SO an opportunity to
| "package" the submitted <data-element>s in a meaningful way.
| But -- alas, once a package is specified, I don't see an easy way to allow
| it to be amended, only replaced.  The replacement would have a different
| and a different URN, e.g. My_Package_Ver1.1 might become

Well, that's a good reason not to register a subission package as
though it were a logical whole, I'd say.

So, although I'm almost ready to give up on the issue (Robin, where
are you?), I think we need to provide a way for the metadata for
each submitted item to indicate what larger conceptual whole (Docbook
3.1, The Docbook DTD - all versions) it is a part of.  If we did that,
the SO could indicate to the RA what pigeonhole to file the item
in when it's registered.  For example, dbpool.mod for Docbook 4.0,
which will be ready soon, would have metadata indicating that it's
part of "Docbook DTD 4.0", and if we can figure out what Docbook 4.0
is, conceptually, it's metadata would indicate that it's a version
of the literary work "The Docbook DTD".

regards, Terry

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

Powered by eList eXpress LLC