Thanks, all, for the discussion on RDDL; the comments received were generally "why RDDL" and "why isn't this optional." In removing the REQUIREMENT and not changing it to a SHOULD we might have thrown the baby out with the bath...
From: William Cox [mailto:wtcox@comcast.net]
Sent: Tuesday, February 28, 2006 9:53 AM
To: Marc Goodner
Cc: Christopher B Ferris; James Bryce Clark; oasis-member-discuss@lists.oasis-open.org
Subject: [oasis-member-discuss] Re: RDDL thread
I've changed the subject to "RDDL thread" so we can view these more easily.
There's been more productive discussion on this topic in the past 72 hours than in the previous review. Please, however, resist the urge to pile on... :-)
bill cox
Marc Goodner wrote:
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.
Marc Goodner
Technical Diplomat
Microsoft Corporation
Tel: (425) 703-1903
From: Christopher B Ferris [mailto:chrisfer@us.ibm.com]
Sent: Tuesday, February 28, 2006 5:31 AM
To: William Cox
Cc: James Bryce Clark; oasis-member-discuss@lists.oasis-open.org
Subject: Re: [oasis-member-discuss] Re: [members] Membership and Public Review of OASIS Artifact Standard Identification Scheme for Metadata
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