Re: XML.org implementation (Packages)

[Len Gallagher <LGallagher@nist.gov>]

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
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
DED1 would get assigned identifiers and be registered.  A request to
retrieve the metadata for DED1 would get the original submitted
<data-element-dictionary> and a request to retrieve the item DED1 would get
a set of two items, A and B.  Later he submits the <data-element>s for C,
D, and E together as part of a <data-element-dictionary>, call it DED2.
Then four items, C, D, E, and DED2 would get assigned identifiers and be
registered.  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).
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.

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.

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!

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.

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.

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.

Since no "uses" associations have been declared a request to retrieve an
item and everything it uses will just get the item.

Again, there is no way to get all 5 parts without explicily asking for DED1
and DED2 together.

However, if the <data-element-dictionary> for DED2 had declared a "uses"
association with DED1, then a request to retrieve registered item DED2 and
all of the items it "uses" would get the 5 parts.

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
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
have this at present and a general facility for amending previous
submissions could get very complex!  If we ever do consider it, the part
that allows additions to a <data-element-dictionary> may look something
like the following:

   AMEND ITEM <uri-reference>
     INSERT ELEMENTS (<data-element>*)

   NOTE: this declaration is valid only if <uri-reference> identifies a
<data-element-dictionary>

Under our existing specification the only way to amend a registered item
would be to replace it with a completely new version, and mark the original
one as "withdrawn", and have the replacement declare a "supersedes"
association with the original.


















At 12:39 PM 4/3/00 , Nagw wrote:
>Please look at my comments on your DTD example below
>
>Regards,
>Nagw
>
>> X-envelope-info: <tallen@sonic.net>
>> Date: Sun, 2 Apr 2000 11:51:07 -0700
>> From: Terry Allen <tallen@sonic.net>
>> To: regrep@lists.oasis-open.org
>> Subject: Re: Re XML.org implementation
>> 
>> Nagwa wrote:
>> | There are two things I would like to report to the regrep TC from the
last 
>> | XML.org meeting:
>> | First, The terminology used in Registration Status List ("certified" and 
>> | "standardized") needs to be modified (due to legal risks).
>> 
>> Those were the values from 11179.  In fact, the values should be
>> chosen by the RA, so we shouldn't specify anything.  I'll replace
>> that list with CDATA.
>> 
>> | Second, The solution we thought about for the package submission is: 
>> | All the Package's components will be an individual object with its own 
>metadata 
>> | and its own unique identifier, but they will be all package together 
>with a 
>> | package unique identifier and metadata. This  will allow the retrieval 
>to be 
>for 
>> | a component only or for the all components this package include.
>> 
>> 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).    We've been discussing this since 11
>> March, is it really unclear?
>> 
>
>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.
>
>
>> | I will be waiting for your feed back, and I can discuss it more
further in 
>our 
>> | next con call.
>> | 
>> | Regards,
>> | Nagwa
>> | 
>> 
>> regards, Terry
>

**************************************************************
Len Gallagher                             LGallagher@nist.gov
NIST                                      Work: 301-975-3251
Bldg 820  Room 562                        Home: 301-424-1928
Gaithersburg, MD 20899-8970 USA           Fax: 301-948-6213
**************************************************************