MHonArc v2.5.0b2 -->
tab message
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]
Subject: artifact naming guidelines
Last month you agreed to delay final action on the Artifact Naming
Guidelines at my request so that we on staff could evaluate whether it can
be implemented technically by our current (or anticipated) technical tools.
You asked that I reply by today's meeting. It's my understanding that you
hope to move it quickly to the Board of Directors.
We appreciate your accommodation so that staff could review its
implementability.
I haven't yet seen the anticipated post-November revisions to the ANG.
Based on the version available in November, my personal opinion is that the
ANG is likely to be a good basis for our eventual naming solution across a
wide variety of naming spaces. We tremendously appreciate the volunteer
expert time and thought that has been contributed to
this project. However, there are unresolved issues which, if if they
prove to be valid concerns, would risk causing significant disruption and
cost to OASIS and its members.
In large part I fear that this is our fault, as staff, as we may not
have brought our entire problem set to your attention effectively, during
the long TAB development cycle of the Guidelines drafts. We apologize for
the resulting delays. I regret to report that, due to the degree of
uncertainty, I will vote against the final adoption of the ANG at this time,
as a TAB member, and recommend against its approval or action by the Board
as premature, if it is forwarded for action at this time. I still think
that most, or all, of the ANG will work just fine -- but I need to *know*
that with more reliability that has been achievable without testing.
Among the concerns we have on staff are the following. it is
possible that they are ALL resolvable, and some may even prove WRONG, but
to support taking the ANG to the Board before I *know* that they are resolved
would not be responsible of me.
1. Rules of this kind create expectations, and users start blowing
conformant documents into our server (and links dependent on them)
archivally as soon as they're declared. So any problems become very
entrenched and hard to fix, if exposed after the rules are in production.
Generally we should institutionally be biased in favor of "right" over
"fast".
2. The production rules for file-naming support no length limit --
which is perfectly acceptable for some applications (such as most machine
readable file trees) , but creates some significant display and handling
problems under some presentations (such as Kavi) and OSes. Tech staff has
called our attention to the latter, which may in some cases be a hard
limit, so I believe testing would be prudent before implementation. As
with Kavi's
recent upgrade, we hope that, by testing, we can roll out changes with
minimal degradation of our information practices. I think that some
testing here is essential, and our tech staff agrees.
3. We are examining document management systems, as a functionality
added to Kavi. Like Kavi, many of them have both coded filenames (such as
would appear in a file tree) and text field "names" (such as appear in
Kavi's current 'documents' repository presentation layer). Current TC
practice in attempting to conform to the ANG (or its predecessor rules) is
to use the same data for both. This strikes me as almost certainly wrong,
as it fails to permit the inclusion of richer semantic information that
might be essential to finding tools. Over the next year we will be adding
features, and increasing our >10000 document repository significantly,
which will aggravate that problem.
4. I would like to have several of the taxonomies for elements of a
name better specified, before it is rolled out and we encourage people to
conform their uploads to it. I recognize this my problem, not yours, as
the ANG leaves this to staff. But it still may affect the proper release
date. As an example, current practices with versioning numbers are,
privately, virtually random, and certainly insufficiently extensible or
predictable.
5. Finally, I have significant doubts about the wisdom of making
these 'guidelines' a Board action item, for policy reasons, and for that
reason alone would at this time oppose that, even if the ANG contents were
wholly final and acceptable.
Several of you have suggested to me that "we're the TAB, so we *must*
send everything to the Board." Whether or not that is an accurate
statement of the current TAB charter, it strikes me as a misunderstood
limit and an unnecessary obstacle to leveraging of the TAB's expertise. I
would like to work with you and the Board to renegotiate that. We have an
upcoming overlapping F2F in January which should facilitate this.
Thanks again for your willingness to take on board our staff
implementation concerns in your deliberations.
JBC
~ James Bryce Clark
~ Director, Standards Development, OASIS
~ +1 978 667 5115 x 203 central office
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]