[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: SubmissionPackage DTD
RegRep, I was on a roll today so attempted to define a SubmissionPackage that would allow a Submitting Organization the ability to request registration of multiple items in the same submission, to request withdrawal or replacement of previously registered items, or to register a "package" of items. A preliminary attempt is attached as a "txt" file. Sincerely, Len Gallagher
<!-- OASIS SubmissionPackage DTD Version 1.0 13 April 2000 Len Gallagher - OASIS RegRep participant The purpose of the SubmissionPackage DTD is to provide a convenient way for a Submitting Organization to submit registration requests to a Registration Authority. This form is a generalization of SingleItemSubmission2 previously proposed. Semantic Rules from that submission form also apply to this form. At some point a combination of the two forms might replace each of them. --> <!ELEMENT SubmissionPackage ( submission-header, submission-item+ ) > <!ELEMENT submission-header ( submitting-organization, --as defined previously simple-contact+, --as defined previously registration-authority --as defined previously ) > <!ELEMENT submission-item ( register-xsgml-entity | withdraw-registered-item | replace-registered-item | register-package-of-items | etc. ) > <!ELEMENT register-xsgml-entity ( simple-contact*, --as defined previously xsgml-entity-reference, --as defined previously local-reference-name, --as defined previously data-element --as defined previously ) > <!ELEMENT withdraw-registered-item ( urn-reference --as defined previously ) > <!ELEMENT replace-registered-item ( urn-reference, --as defined previously register-xsgml-entity --as defined above ) > <!ELEMENT register-package-of-items ( simple-contact*, --as defined previously local-reference-name, --as defined previously package-contents, version?, --as defined previously definition-text, --as defined previously name-context+, --as defined previously classification*, --as defined previously data-element-association*, --previous defn enhanced as below related-data-reference* --as defined previously ) > <!ELEMENT package-contents ( <urn-reference>*, --as defined previously <register-xsgml-entity>* --as defined above )+ > <!ELEMENT data-element-association --this is an enhancement of previous defn ( data-element-association-label?, --as defined previously ( urn-reference --as defined previously | local-reference-name) --as defined above )> <!ATTLIST data-element-association association-type ( uses | used-by | supersedes | superseded-by ) #REQUIRED location (local | external) #IMPLIED > <!-- SEMANTIC RULES for <SubmissionPackage> 1) All rules from <SingleItemSubmission2> apply here. 2) The <urn-reference> in a <withdraw-registered-item> element is a URN that uniquely identifies an item previously registered in this registry. The RA marks the <registration-status> of the identified item as "withdrawn" and sets the <withdrawal-date> to an appropriate value. The identified item may be deleted from the Repository, but information in the Registry is left intact for some agreed period of time. 3) The <urn-reference> in a <replace-registered-item> element is a URN that uniquely identifies an item previously registered in this registry. The RA marks the <registration-status> of the identified item as "withdrawn" and sets the <withdrawal-date> to an appropriate value. The identified item may be deleted from the Repository, but information in the Registry is left intact for some agreed period of time. The RA will add a new association of type "superseded-by" to the registry entry for the XSGML-entity identified by the <urn-reference>. [ISSUE: Is it an error if the new item doesn't have a "supersedes" association with the replaced item?] 4) A <local-reference-name> contained in a <data-element-association> must match uniquely a <local-reference-name> contained in a <submission-item> of the same <SubmissionPackage>. 5) A <urn-reference> in a <package-contents> element is a URN that uniquely identifies an item previously registered in this registry. That item must have been submitted by the same SO and must not already be contained in some other package. If either of the above is false, then no action is taken for that item and the SO is notified. Otherwise, the previously registered item is marked as being part of the newly registered "package" item. [NOTE: This rule assumes that an item is contained in no more than one package. If that is considered too restrictive, then we could add the "distributed- within" alternative to the <association-type> attribute of the <data-element- association> element. There are some advantages to keeping physical package containment more restrictive and instead rely more on the "uses" association.] 6) A <register-xsgml-entity> in a <package-contents> results in that entity being registered as if it had been a separate <submission-item>. In addition, that registered item is marked as being part of the newly registered "package" item. -->
************************************************************** 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