Re: The Simple Case

[Terry Allen <tallen@sonic.net>]

Jon wrote:
| There's a question for Una and Nagwa toward the end of this.
| 
| [Terry Allen, back in his posting of last Saturday:]
| 
| | Actually, I don't think anything in the current spec prevents
| | the simple case from being simple (if we omit the material about
| | submissions, which I have suggested in a separate message).  There
| | is something that needs to be added, and on one point we have a 
| | divergence of views.
| | 
| | The thing that needs to be added is a notion corresponding not
| | quite to "a principal registered item" (it's pretty hard to figure
| | out what that would be for, e.g., the Docbook DTD; suggestions
| | welcome)
| 
| I would have guessed driver.dtd to be the principal registered
| item.  Am I missing something?

Not necessarily; it's the place to start parsing, the item that bears
the identifier that goes in the DOCTYPE decl; but what if you had a 
flattened version of Docbook registered, too?  Then there would be 
two places to start parsing, and arguably two principal registered
items.  I think the idea of a PRI isn't useful for us; I tossed it
in to elucidate.

| | and not quite to "submission": it's the key by which the thing to
| | which related data are related is identified for purpose of
| | display in the list of related data.
| 
| Is this what data-element-concept is for?  Sounds like it from
| your documentation:

Possibly; I'll have to reflect on whether we would be stretching
11179 if we used it this way.
...

| | For the purpose of the dbrelated.txt example I made this the
| | entire Docbook distribution, but as noted above, that's a
| | simplification, as the set of related data may not be the same as
| | the distribution.
| 
| I don't see dbrelated.txt on the public page, and I don't seem to
| have a working password at the moment, so I don't actually have an
| example of this in front of me at the moment; my apologies.

  http://www.oasis-open.org/html/dbrelated.txt

| | It's more like a node in a taxonomy (or other classification) of
| | DTDs.  We can make this something abstract (that is, not any of
| | the registered items).  It would correspond to the notion of a
| | literary work: the Bible is a literary work with many versions and
| | physical instantiations, none of which is primary in the way a
| | book's first edition can be.
| 
| Yes.
| 
| | We might instantiate this notion as the name of an item in
| | a classification scheme, so that "Docbook DTD" would be such
| | an item.
| 
| Due to my unfamiliarity with the spec, I'm not quite sure what you
| mean by this.

I was thinking of making the totality of all the versions of Docbook
a node in a taxonomy (only I wasn't sure that it should be a taxonomy
so I used the more general 11179ism, "classification scheme"); above
you suggested using data-element-concept for the same effective 
purpose.
...

| | I understand Una to want it to be possible to have registered
| | items that don't have registry entries or metadata, except that
| | which is inherited from the submission in which it arrived.  This
| | simplification won't do in an implementation of 11179, and I think
| | it's not right anyway.  In the 11179 model everything has
| | metadata: its SO, its representation, its name, and its name
| | context, for starters.  Representation, name, and name context
| | cannot be inherited from another registered item, nor from the
| | submission.  Una mentioned language during the ACXO meeting; that
| | too cannot be inherited.
| 
| This seems to be the nut of the problem.

Yes.

[the rest clipped]

regards, Terry