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: NOTES from 13 March 2000 concall

The following are minutes taken at the 13 March 2000 meeting (a
teleconference) of the Advisory Committee of XML.ORG (ACXO).

ACXO Chair: Executive Director of OASIS
 ACXO members:
   Chair - OASIS Executive Director (Laura Walker)
   CommerceOne (Terry Allen)
   DataChannel (Norbert Mikula)
   Documentum (Una Kearns)
   IBM (Michael Weiner)
   Sun Microsystems (Simon Nicholson)
   Nagwa Abdelefour
   Jon Bosak
   Craig Chevrier


Policy Questions/Issues

DEFERRED (see note below)
Q1. What can people submit?
A1. A package of stuff: schema, related documentation, FAQ, with
accompanying metadata

DEFERRED (see note below)
Q2a. Shall submissions be uniform and if yes, what should they include?
A2a. - schema
    - sample instance
    - supporting documents

Q3. Is every submission reviewed before being accessible on the repository?
A3. In the first implementation, there shall be a human review of every
Submitting Organization (SO) and each submission (initially).

Q4. Do we allow/enable uniqueness (e.g., by assigning an identifier)?
A4. Submissions should come in with an identifier (e.g., URNs), there is
therefore no need for XML.ORG to assign an identifier. RFC2483

Q5. Are updates allowed?
A5. We will allow:
    - Add a new version
    - Add a new version and it supercedes the old one
    - Replace a submission (i.e., retraction) --
      but only through a human review process
    NOTE: We must decide policy on whether and how
    reviewer replaces submissions
    ACTION ITEMS: Write up use cases (ALL: deferred
    to a future meeting)

Q6. One contact per submitting organization (SO)?
A6. Yes. But we must clearly communicate that a SO can be any entity (e.g.,
a department within a division within a company). This information should be
presented on the submission form, with some kind of feedback when a
previously registered SO attempts to register under another contact name
(e.g., "Sorry: We already have a contact person for this SO. Please try
another SO.)
NOTE: must allow some way to update contact person for SO. The RA is
responsible for authenticating the contact and SO.

Q8. Taxonomy
A8. Use what we're using now (NAICS). User should self-classify.

Q9. Minimum Browser Support
A9. For submitter - R4.0 and later
    For browser/user - follow WAI guidelines

Q10. What should be available for System Download?
In the first implementation the metadata is available via UI, but may not be
available for system download (dependent upon development).

- In order to answer Questions 1-2b, all must read T. Allen email of
Saturday 11 March and Len Gallagher's (NIST) answer to submission content
question, forwarded by T. Allen on Monday 13 March.

- Nagwa to write up URN resolution

"Business Relations" aspects to be discussed
- To SO: If you need to update your contact person, please call or email.

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

Powered by eList eXpress LLC