Re: XML.org implementation (Packages)

[Terry Allen <tallen@sonic.net>]

Len wrote:
| All,
| 
| I'm confused both by Terry's example and by Nagw's response to it.  The
| entire correspondence is included below.
| 
| First - take Terry's example:
| 
| > Please refer to my initial post on "the simple case".  The fact
| > that several things happened to be submitted together doesn't
| > mean that it's useful to maintain that association.  In other
| > words, if my DTD has parts A, B, C, D, and E and I happen to submit
| > A and B together, then later C, D, and E, the useful set is A-E,
| > not (A, B) and (C-E).
| 
| It's not clear if Terry intended to say DED for <data-element-dictionary>
| or if he really means DTD for <data-type-definition>.  But I'm having

DTD.  Docbook comes in half a dozen modules.

| trouble with either interpretation.  Let's assume DTD for now.  Suppose he
| submits the <data-element>s for parts A and B together as a
| <data-element-dictionary>, call it DED1.  Then all three items A, B, and

Each module is a d.e.d.; they aren't submitted together as a d.e.d.

| ...  At this point the DTD that uses all 5 parts is still not
| registered.  If the DTD "uses" all 5 parts, it couldn't be registered with
| parts A and B because its "uses" associations with C, D, and E wouldn't be
| valid (unless they were registered in some other registry/repository).

The DTD is *composed of* all five parts.  Now, in my Docbook examples,
I also showed the whole set of Docbook parts registered together,
db7.txt.  I was simplifying in the example that confused you.

| However, its <data-elemnt> with the DTD metadata could have been submitted
| along with parts C,D, and E in the <data-element-dictionary> DED2, or it
| could be submitted separately.  It each case the <data-element> for the DTD
| would be assigned an identifier and its metadata would declare a "uses"
| association with the five parts A-E, or it could declare a "uses"
| association with the package DED1 and items C,D, and E, or if submitted
| separately, it could declare a "uses" association with packages DED1 and DED2.

The essential points here are:  1) as Len indicates, the declared
associations show what goes together with what (the accident of
submitting things together does not), and 2) we need some notion
of a DTD apart from its modules.  In my message "Literary Work,"
I gave this view:

| REGISTRY
| 	List of Subject Areas
| 		Aircraft
| 		(etc.)
| 		Computer Documentation
| 			IBMIDDOC
| 				IBMIDDOC 1.0 and related data
| 				IBMIDDOC 1.1 and related data
| 			(etc.)
| 			Docbook
| 				Docbook 3.1 and related data
| 				Docbook 4.0 and related data

and asserted:

| The List of Subject Areas is clearly a classification scheme, it clearly
| isn't owned by the SO for Docbook, and it may or may not be owned by
| the RA.  I'd call it a taxonomy.  Computer Documentation is a node in that 
| taxonomy.  IBMIDDOC 1.0 (for those who've never heard of it, it's a 
| documentation DTD from IBM) is a d.e. dictionary, as is Docbook 3.1.  
| (In both cases, the related data isn't part of the dictionary.)

In the case of Docbook 3.1, the entire distribution could be considered
the storage entity most closely associated with the line

| 				Docbook 3.1 and related data

or you could take the view that docbook.dtd, which is the "driver"
file that calls all the other modules, is the storage entity most
closely associated.  But actually, I think, you'd want to see under 
that line,

					entire distribution
					docbook.dtd
					dbpool.mod
					dbhier.mod
					related data

So maybe "entire distribution" should be regarded as a data-element-
dictionary-set.  

| A request to retrieve the registered item DTD would get a single document
| type definition that references 5 other registered items, but it would not
| receive the other 5 items themselves.

That would depend on whether you wanted to retrieve the entire 
distribution (as you probably would when browsing) or the docbook.dtd
file (as a result of a call from a parser).  Both choices are 
reasonable under different circumstances.

My point in the example that confused you was that it should not
matter if I submit docbook.dtd and dbpool.mod one day, and dbhier.mod
and other modules the next:  remember, I'm not taking "submission
package" as meaning the same as "set of all associated registered
items" (I had previously used "set of all related data", but that's
something different still).

An RA *could as a matter of policy* require a set of all associated
items to be submitted as a single submission package, but that would
not extinguish the distinction between submission package and set
of all associated items, it would only treat them as functionally
equivalent for the purpose of that RA's workflow.

That this policy would be difficult to live with can be seen more
clearly when one considers related data.  If I submit a DTD and
documentation, then add related data, such as a FAQ, examples,
and so on as they're created later - perhaps even new DTD modules -
I have no particular interest in dealing with the original
submission package boundaries.

| A request to retrieve the registered item DED2 would get items C,D, and E,
| and possibly DTD if the <data-elemnt> describing DTD was included in DED2.
| However, in no case would it be possible to request a single registered
| item and get everything!

In the example that confused you, right (unless the RA created a
package of them); in my Docbook examples, no, you could request
the entire distribution.

| A request to retrieve the item DTD and all of the items it "uses" would
| retrieve 6 items, i.e. the DTD and the 5 parts. But this requires a
| recursive search on the part of the registry/repository down the "uses"
| association tree for DTD - I see this as a feature of a "good"
| registry/repository.

Certainly the "uses" associations need to be arranged so as to make
this possible.

| In this example Terry is making the point that DED1 and DED2 really have no
| relevance to the DTD and its 5 parts, but the registry/repository doesn't
| know that.  The repository has no choice but to register DED1 and DED2 and
| keep any metadata that was included with them.  Una would say - let's not
| register DED1 and DED2 and lets not make it possible to associate any
| metadata with them.  That's OK, except then we'd have lost the capability
| to register packages of elements and to reference the package with a single ID.

Yep.  And that's why we probably need the notion of a literary work,
which both RA and SO can use to draw a boundary around "Docbook DTD",
and why we probably need to consider Docbook 3.1 as a d.e.d.-set.

| Next -lets consider Nagw's interpretation of Terry's example.  I think Nagw
| was assuming that Terry wanted to register a package with 5 parts, not a
| DTD with 5 separately specified and registered sub-elements. Here's what he
| says:
| 
| >I think we are in the same page here, 
| >There will be a unique identifier for the DTD, and a unique identifier for 
| >every 
| >component from A-E. 
| >We will use the DTD unique identifier to group all related submission , i.e 
| >(A,B) with (C-E)
| >When you retrieve the DTD , it will includes A-E. 
| >You can also retrieve each component separately.
| 
| Even under the assumption that we're interested only in the 5 parts, not a
| document that uses the 5 parts, and that Terry meant to say DED instead of
| DTD in his example, things don't happen as Nagw expects.
| 
| 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.
...

| CONCLUSION
| 
| What Nagw really wants here, I'm infering, is the ability to register a
| package of items and then add other items to the package later.  This will

I certainly want that.

| be very difficult to accommodate unless we specify a DTD for a submission
| to a registry that allows one to amend a previous submission.  We do not

No, submission is related to workflow, not to registered items.  We
need instead to be able to specify associations, and associations
to larger entities than a given registered item (and those associations
aren't yet in data-element-association-list.ent).  Those larger
entities keep getting confused with "submission packages", but they're
different.

regards, Terry