Regarding
RDDL, I agree
with Chris’ comments below particularly that anyone who thinks it isn’t
browser accessible doesn’t understand it. RDDL is simply metadata in an
html file. Probably even better than the link Chris provided below is a
link to
the actual namespace for the CD2 of WSRM and WSRM Policy so you can see
RDDL in
action (in your browser).
WSRM http://docs.oasis-open.org/ws-rx/wsrm/200510/
WSRM
Policy http://docs.oasis-open.org/ws-rx/wsrmp/200510/
If
someone were to
look at the CD for either one of those specs, that is the namespace
they would
find there. You can see how the information provided there is much
better than
simply a directory listing. I do not understand why we would not want
to pursue
this in a way that could be consistently applied across the
organization.
Furthermore
I have
gone back and looked at the public comments to this list and see no
suggestions
that RDDL should not be used. I saw requests for more guidance on how
to use it
and that it should be optional. To simply remove it does not address
the
substance of the comments or assist TCs that do want to use it.
Bill,
Some
further commentary. Due to the way in which Notes will mangle the text,
I have
prefixed your comments with WC:
line
350 - what does "associated" mean? How is such an association
effected? I am associated with the TAB
by virtue of being an alumnus. However, I am not IN the TAB.
WC: The expression is covered elsewhere; see for example lines 501-503
(XHTML,
etc), 509-511 (significant comments),
WC: 517-518 (already done in document templates), and 525-526. In most
WC: of these the association is "included in the cover page or meta
tags."
My
point was that the use of the term "associated" was not clear. Maybe,
what is called for is a section unto itself
that
explicitly states the permissable/recommended means by which metadata
may be
"associated" with an
artifact
and any time the term "associated" is used, make a reference to that
section.
WC:
The templates were modified some time ago; if you're
using the
4/15/05 IPR statement template you're providing pretty much the full
set of
metadata.
If
that is the case, then I think that the ASIS should be changed to
reflect this
fact, rather than to suggest that it SHALL be done.
line
492 - states:
The relevant required metadata for an artifact MUST
be maintained at the default index page for the http scheme URI for
each product
and productVersion to facilitate search and retrieval.
WC: Take a look at the spreadsheet of comments and resolutions from the
previous review. There was a lot of
WC: complaint about RDDL, based on standardization status (not much)
and
preference to have an index.html
WC: or one of the other default HTML pages. My thought is that a web
browser-presentable document is important,
WC: and that OASIS should provide a template. Again, the first
reviewers
rejected RDDL pretty consistently.
What
is clear to me, at least from the statement above: "and
preference to have an index.html" is that those who
made
such
comments don't know what they are talking about. How is "and
preference to have an index.html" somehow
inconsistent
with using RDDL in an index.html page? Further: "My
thought
is that a web browser-presentable document is
important, " How is use of RDDL
inconsistent with a
browser-presentable document? Clearly, it is not. Check out the
proposal
that is working its way through the WS-RX TC [1]. It may not be
perfect, but it
seems to satisfy the requirements
nicely.
Finally,
with regards to the "standardization status", I think that is a red
herring. A standard does not value yield value
simply
by virtue of its status (although many would claim that to be the
case). What
makes a standard valuable is
how
broadly it is adopted. A common convention can become a de facto
standard
simply because it is broadly
adopted.
"RSS" is such an example. While there may be a few flavors kicking
around, and only one form of "RSS"
is
a true standard (IETF's ATOM) sanctioned by an SDO, the various flavors
have
yielded significant value by
virtue
of the fact that the many RSS feed readers have done a pretty good (not
perfect) job of supporting them all.
What
form must this take? A RDDL document? I guess I am a little confused as
there
seems to be no guidance as to how the metadata is to be captured in the
"index.html" page. What does this page look like? Does it then
provide links to the various forms of the document that can be
retrieved? Why
is so little of the
"Required Metadata" that MUST be "associated" with the
artifacts included in this "index.html" page's <meta/> tags?
Why wouldn't the metadata also be
exposed visibly on this page?
WC: For each artifact?
No.
Check out the WS-RX RDDL example [1]. It supports multiple links and
provides a
formal way of "associating" the relevant
metadata
that is both human and machine consumable. IMO, that satisfies the
requirements.
Thus,
the specific lifetime of a URN is FOREVER. Period. Anything else is an
abomination of the whole concept of a URN, regardless
of its purpose.
WC: "persistent" doesn't mean "eternal." The resolvability
of namespace URIs in general seems to create much
WC: heat (and a little light); the purpose of these "temp URNs" is to
reserve URN space for those groups that
WC: consistently use URNs. If namespace URIs aren't resolvable either,
that
creates a problem for having
WC: something browsable at the namespace URI...
What
part of "persistent" [2] is not clear?
per·sis·tent
( P ) Pronunciation Key (p
r-s
s
t
nt, -z
s
-)
adj.
1.
Refusing to give up or let go;
persevering obstinately.
2.
Insistently repetitive or continuous: a persistent ringing of the telephone.
3.
Existing or remaining in the same
state for an indefinitely long time; enduring: persistent
rumors; a persistent infection.
Nothing
is eternal. Maybe I was a bit overboard with FOREVER, but any notion of
"temporary URNs" is completely
inconsistent
with the whole premise of URNs.
[1]
http://www.oasis-open.org/apps/org/workgroup/ws-rx/email/archives/200601/msg00104.html
[2]
http://dictionary.reference.com/search?q=persistent
Cheers,
Christopher
Ferris
STSM, Software Group Standards Strategy
email: chrisfer@us.ibm.com
blog: http://www.ibm.com/developerworks/blogs/dw_blog.jspa?blog=440
phone: +1 508 377 9295