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)


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