MHonArc v2.5.0b2 -->
oasis-member-discuss message
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]
Subject: Re: [oasis-member-discuss] Re: [members] Membership and Public Review ofOASIS 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 itselfthat 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 madesuch comments don't know what they are
talking about. How is "and preference to have
an index.html" somehowinconsistent 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 theproposal that is working its way through
the WS-RX TC [1]. It may not be perfect, but it seems to satisfy the requirementsnicely.Finally, with regards to the "standardization
status", I think that is a red herring. A standard does not value
yield valuesimply by virtue of its status (although
many would claim that to be the case). What makes a standard valuable ishow broadly it is adopted. A common
convention can become a de facto standard simply because it is broadlyadopted. "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 relevantmetadata 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
completelyinconsistent 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=persistentCheers,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
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]