OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

acxo message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]

Subject: Re: XML.org Registry and Repository Functional Specification

about 29 hours ago, out of the 48 allowed, I wrote

>Thanks, Una.  I'm not sure we ever formed the group to respond.
Does anyone recall better than I?

I have taken the liberty of composing a reply to Una's document, below.
I suggest we do one more round, and in the meantime SOMEBODY HAS TO

Else we might as well quit now and stop fooling ourselves that as
a group we really want to do anything.  Sorry to resort to upper case,
but we need to act responsibly.

best regards, Terry

Terry's Comments
16 Feb 00

General:  This is pretty much I had hoped to see.  I have a bunch 
of minor comments and one major one, which is that some of what
is called "Repository" we have in the past called "Registry Interface".
I'll point out where that comes into play at the appropriate points.

I would also really appreciate it if such documents were not
composed in Word; for OASIS purposes either HTML or plain text
would be preferrable.  I myself cannot use Word to add comments
to text, so I've saved the original as text here.

| XML.org Registry and 
| Repository
| Documentum and 
| Sun
| Docbase Version 1.0

actually version 1.1, updated, accd to the Revision History

| Tuesday, February 15, 2000
| Una Kearns

| 1 Introduction

| 1.1 Conformance
| We will attempt to conform to parts of ISO 1179 that are 

It's ISO 11179.


| RA	Registered Authority

should be Registration Authority

| The registered authority is XML.org/OASIS. 

Should be OASIS, I think; XML.org exists only as an advisory

| Repository
| The repositry provides search and system access to 
| registered objects.

This is the major comment:  the repository (according to the
world view of the spec) only holds stuff; the interface is
logically part of the registry interface.  (I understand that
in implementation the lines may get drawn differently, but
that's an implementation-specific matter.)

| 3 Roles
| This section outlines the defined user roles of the 
| registry and repository

And is mostly pretty good.  Unfortunately Word saves tables
as text in a single column, so I'll be quoting and paraphrasing.

Throughout, in most cases where "Repository" is used, I'd say 
"Registry".  For example, Guest User/Repository/Functions,
is mostly about the registry interface; "download" can be a
call through the registry to the repository.
Guest System/Functions, "Include URI as specified ..."  What
does this mean?

SO System/Registry/Functions, "registers new submissions"
should be "submits new submissions".  "Respond to clarifications"
means what?

RA Web Design, "Creates/Alters", add "Deletes"?  "repository
interface" is what I think of as "registry interface".

RA Business Analyst, I'd think that "adds and removes users
from groups" is a task for the RA Admin.

There's another role here, too:  RA Registrar, the person
of authority who manages all the RA roles now listed.

| 4  Registry and Repository Solution 

| 4.2 Overview
| The registry is where organizations submit schemas and 
| related information for registration to the XML.org 
| repository.  

"for registration." is enough.

| Through the registry organizations can also 
| update information related to a registered schema.  
| When new (or updates to) schemas and related 
| information are “approved” for the repository, updates 
| are automatically pushed to the repository.  Through the 
| repository, a user can search and browse for schemas 

Through the *interface to the registry* a user can etc.
Recall that the interface is constructed from information
in the registration documents (plus classification schemes,
which need to be stored in the repository, but we're not
making much of that for this prototype).

| and download files.  Automated system access to the 
| repository can be through using standard identifiers 
| (URLs).

URIs.  We really do want to use the RFC 2483 mechanism, see below.

| 4.3 XML.org Web Page Layout
| The registry and repository must to be seamlessly 
| merged into the XML.org site.   

I don't see that; we don't need to worry about how they
are integrated into the XML.org site for the purpose of this

|  This is not to be 
| considered the full design of the XML.org site but its 
| purpose is to illustrate the scope of functionality and our 
| understanding of the requirements.

In the diagram, I would join the boxes "Registry" and "Repository"
as "Registry Interface".

| When a SO logs in to the registry a page will be 
| displayed listing all of their current submissions and a 
| link to allow them to enter new submissions.  For each 
| submission there will be links to allow them to update 
| and view the status of the submission.  There will also 
| be an “inbox” area that may contain routed submissions 
| and comments from RA_SMEs and RA_Admin.  

Could you explain that last sentence better?

| When any submissions are routed through the workflow 
| process an email will be sent to the receiving person 
| with a link to direct them to the registry login page and 
| indicating what has been routed to them.

That's not entirely clear to me.

| When a user goes to the link “register as a submitter” 
| they will be presented with a screen to fill out information 
| about their submitting organization.  When they submit 
| this information it will be sent to somebody in the RA 
| (possibly the RA_Admin or RA_SME).  The RA will verify 
| information from the SO and will then set-up the new SO 
| in the system.  This will involve adding the user and 
| potentially creating groups for the SO.  The RA will then 
| inform the SO of their username and password and tell 
| them that they can now begin submitting to the Registry.

Again, in this diagram (page 12), I think the top box is
"Registry", not "Repository".

| The repository does not require login to access the 
| functionality.  From a user interface standpoint the 
| repository has two main ways of finding submissions.  



| ? An editor sees a reference to a DTD and retrieves it, 
| ? A validating parser sees a reference to a schema and 
| fetches it. 
|  The simple lookup will accept an HTTP GET, parse the 
| URI and then return a single object that matches a 
| lookup on the URI.

Please let's use the RFC 2483 mechanism.  It shouldn't add
any complexity to the implementation; we don't have to
implement all the possibilities, but if we don't start out
this way we won't have any way to retrieve by URNs, or FPIs,
or anything but hard-coded URLs, which I think would be
a failure.

| 5 Registry 
| This section provides detailed descriptions of all the 
| functionality associated with the Registry.
| 5.1 Requesting to be a Submitting Organization

In this diagram, to the top box add "after reading legal
notices, etc."

In the next box down, "contact info" is SO's contact info, right?

In the next box down, "submitter request" is unclear.

At this point, I think the workflow is to the box over on
the left and then to the fourth box down the stack, with
no direct connection between the 3rd and 4th boxes.

In the 4th box, the RA also assigns a unique ID to the SO.

| The information submitted on the request to be a 
| submitter is:
| ? Name of Submitting Organization
| ? URI Reference of SO 

means what?  SO's home page or RA's unique ID for the SO?

| ? Description of Organization

(not in the spec, but okay by me)

| ? Address of Submitting Organization
| ? Postal Address
| ? Email
| ? Telephone
| ? SO Contact Information
| ? Name
| ? Address (as above)
| ? Username
| ? Password 

add Occupation Title (you want to know how to address them)

| 5.2 New Submission
| Role: SO
| A SO can go to the registry and add a new submission.  
| A submission consists of one data-dictionary-element; 

one data dictionary.

| submissions of data-dictionary-element-sets and 
| classifications will not be supported in this release.  


| A submission consists of the following:
| ? Metadata about the submission, which is a combination 
| of identifying information, administrative information, and 
| classification information. Only one classification scheme 
| will be supported for release 1.
| ? One or more components that constitutes the 
| submission. 
| ? The file is imported to the registry, or an external URL is 
| provided.  
| ? A description is provided for each component.

(according to related-entity-list.ent)

| ? An URI identifier is provided for each component for 
| system access.
| ? A format type – e.g. XSL, DTD, Schema, XDR is 
| selected.

(from xsgml-entity-list.ent)

|  Note: If the submission consists of multiple Schemas 
| and Files, it will be up to the SO to provide one file as 
| part of the submission that contains the entire Schema 
| to allow for system access. 
| ? Relationships of this submission to other 
| submissions/data-dictionary elements.
| It will be up to the SO to manually identify and manage 
| relationships to other submissions/data-dictionary 
| elements using the URI Identifier to the submission.
| Example relationships are:

(from data-element-association-list.ent)

| ? uses-exterior
| ? uses-comaintained
| ? used-by
| ? supersedes
| ? superseded-by
| ? distributed-within
| For release 1, no system specific functionality or actions 
| will be associated with these relationships.  They will be 
| listed from the registered objects page when viewed 
| through the repository.
| ? One or more pieces of Related Information (This 
| consists of documentation, FAQ’s, URL links, etc.)
| ? Each related entity is either imported to the registry, or 
| an external URL is provided
| ? A description is provided
| ? The format type is selected
| ? A description of how it is related e.g. Documentation, 
| FAQ.

(from documentation-genre-list.ent)

| When a user selects to submit, the following occurs:


| - The Entire submission is sent via workflow to the RA for 
| approval
| - The RA may then fix any problems or send back to SO 
| for clarification/changes
| - When approved the submission is pushed to the 
| repository.
| New Versions of a Submission e.g.  Docbook 3.0 -> 4.0 
| would be considered a new submission.   Updates to 
| submissions e.g. to Docbook 3.0, fixing errors, adding 
| extra-related information is made as a version to 
| Docbook 3.0 directly. 

Why?  To me they'd all be new submissions; the relationship
to the previous version goes in the registration metadata.

| The manner in which submissions will be implemented 
| will be either using the XML Zip file packaging 
| mechanism or a Forms Interface.  This will be decided 
| upon during design.
| 5.3 Revision of a Submission (Update)
| Role: SO, RA_SME, RA_Admin
| A SO can make changes to a Submission.  This might 
| be because problems were found during the approval 
| stage or added related information became available.
| This basically is the same process available for 
| submitting a new schema. 
| The SO can add newly related components or change 
| metadata.  When the SO is finished making changes to 
| a submission, the submission is routed for approval and 
| the submission XML file is created.  When approved the 
| updated files are pushed to the repository.
| XML.org might also choose to allow RA_SME or 
| RA_Admin to update information regarding submissions.  
| Again either a forms interface will be provided or 
| Updates will be based on XML Zip File packages, this 
| will be determined during design.


| 5.5 Retires and Cancels 
| Roles: SO
| We do not see a difference between retires and 
| cancels.

Cancels means it goes away with no information available
except that it's gone.

Retires means it's still there, but marked "retired".  This
is so you can discover historical info.  

| A SO or RA_Admin may retire or cancel a submission.  
| A user would select a submission and an action cancel.  
| They would be given a choice to enter the expiration 
| date.   When a submission has reached its expiration 
| date it will be removed from the repository and will no 
| longer be available for general access.  The submission 
| will still be stored in the repository and can be re-
| activated again.
| 5.5.1 Metadata:
| Below is the metadata that is associated with each 
| submission.   The table below indicates which metadata 
| is searchable from the repository.

Contact Info/Description:  this should be the contact 
info for the SO, period, not "for the particular submission",
as a later version of the submission is considered a different
submission but shouldn't require renegotiating the contact info.

It's not obvious that all the contact info should be visible to
users.  We don't want people harvesting the email addresses of
contacts and then spamming them.

Status:  the retired status should be visible to general users,
see explanation of retirement, above.

Classification scheme.  I suggest using the existing home-grown
one while we figure out what to do in the future - that figuring
out is not going fast enough for this prototype.

| 5.6 Classifications
| Classifications are only useful if registered submissions 
| are identified as part of a classification scheme or 
| sufficient metadata is captured to automatically classify 
| items.  

Submissions are not part of classifications schemes; you
presumably mean "are identified by classifications drawn from
a classification scheme".

| If we allow adhoc classification schemes then the 
| XML.org registry and repository will be useless. 


| ISO1179 describes the information that needs to be 
| recorded for given classification schemes but it is a 
| methodology to be used by Registries.  A classification 
| scheme needs to be decided upon for XML.org as this 
| will determine the navigation for the repository.

for the registry interface.  Yes.

| It will be critical that SME are available to review 
| classifications.

In the long run, yes; for the prototype, one person should
review them all, to ensure consistency.  BTW, "SME" means
"Small and Medium Enterprise" in the EDI world, so is confusing.

| If a classification scheme is postponed then browsing 
| will not be supported for this release.  Also if the 
| classification scheme is changed, major rework will be 
| required to re-classify all items.  

Agreed.  This is XML.org's problem.  (Now you can imagine 
how to do the reclassification by algorithm, but let's not
discuss that now.)

| For release 1 we will support one classification scheme.


| 5.7 Pushing to the Repository
| The Repository will be updated automatically when 
| changes occur to submissions in the registry. 
| The repository will store all components of a submission 
| and a submission will be the target of querying and 
| browsing based on the metadata outlined above.  An 

No, the registry interface is what's the target.

| XML file will be stored in the repository storing all 
| information to be displayed regarding a submission 
| including links to related files.

Yes, this is where the repository is used to store registry

| The same mechanism can be used for any type of 
| content to be stored on the XML.org site.

Yes.  Depending on what you mean by "the same mechanism".

| 6 Site Design and Maintenance
| If the entire XML.org site is not maintained through this 
| site, it is crucial that the templates for the site are 
| maintained also through the registry (which will update 
| the repository).  There is nothing in the design of this 
| system that would prohibit the entire site being managed 
| through the one content repository.   The registry is 

I don't understand what that means.

| considered part of the content repository, except some 
| of the contributors are external to XML.org for example 
| SO. 

Or that.

| 7 Repository
| This section provides detailed descriptions of all the 
| functionality associated with the Registry.
| The XML.org Repository, Version 1.0 is a location where 
| documents (XML-related entities, including but not 
| limited to DTDs and schemas) populated by a registry 
| reside, and from which they can be retrieved by 
| conventional HTTP means. Except for population of the 
| repository data by the registry, all other interactions with 
| the repository are read only.

RFC 2483 again:
| ? An HTTP GET is done with a URL that specifies a 
| unique ID. 

That's what the RFC 2483 syntax permits.

| ? Repository will lookup data based on the unique ID and 
| then send the object back to the client. 

Yes; I find it useful to imagine that the client always 
interacts with the registry and only the registry requests
info from the repository, AS AN INTELLECTUAL ABSTRACTION.
Obviously for implementation purposes it's okay to hit the
repository directly.

| ? Client will receive the object. 
| Examples
| Some example scenarios of what users might specify 
| and the output they'll view include:
| 1. A user receives a manual that refers to the DOCBOOK 
| DTD by unique identifier and brings the contents up in a 
| structured editor.
| ? Input: The editor makes an HTTP connection to the 
| Repository requesting a GET for the unique identifier for 
| the DOCBOOK DTD at the repository site. 

Actually, in this case we have to figure out how to manage
FPIs; I can think of ways.

| ? Output: The editor receives the DOCBOOK DTD and 
| allows editing of the manual to conform to the 
| 2. A user receives a manual that refers to the DOCBOOK 
| DTD by a URL with a unique identifier for the DTD.

per RFC 2483?  otherwise I don't understand "a URL with a
unique identifier for the DTD".

| ? Input: User specifies URL in browser. 
| ? Output: User receives DOCBOOK DTD. 

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]

Powered by eList eXpress LLC