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)

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 clearly
| defined in the OASIS specification, I'm assuming that it can only be one of
| 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 it):
| <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 have
| 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", the
| <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 ID
| and a different URN, e.g. My_Package_Ver1.1 might become My_Package_Ver1.2.

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