[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: Re: XML.org implementation (Packages)
I think it will be hard for me to try to explain what I mean through e-mails, can we leave my explanation to our con call on Friday? Regards, Nagwa > X-Sender: len@mailserver.nist.gov > Date: Mon, 03 Apr 2000 16:17:57 -0400 > To: regrep@lists.oasis-open.org > From: Len Gallagher <LGallagher@nist.gov> > Subject: Re: XML.org implementation (Packages) > Mime-Version: 1.0 > > > 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 > **************************************************************
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC