OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

oasis-member-discuss message

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


Subject: RE: [oasis-member-discuss] Re: RDDL thread



I am not suggesting that it be mandated, just recommended practice. I frankly don't much
care which version, either 1.0 or 2.0 is effective. We used 2.0 for the WS-RX TC namespace
documents. However, the mere existance of multiple versions of a specification should
not be cause to "forget the whole thing".

GRDDL isn't quite the same beast, although it may have relevance to this endeavor and should
be monitored.

However, refreshing my memory of GRDDL DOES remind me that where practical, OASIS SHOULD be recommending
use of Dublin Core metadata terms [1] when expressing such metadata. e.g. instead
of just "title", use "DC.title" (for XHTML <meta> tags) or "dc:title" with the relevant namespace qualification.

[1] http://www.ietf.org/rfc/rfc2731.txt

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


"Hal Lockhart" <hlockhar@bea.com> wrote on 02/28/2006 02:10:41 PM:

> These are exactly the reasons the TAB felt we could not mandate RDDL.

>  
> Hal
>  
>
> From: Wachob, Gabe [mailto:gwachob@visa.com]
> Sent: Tuesday, February 28, 2006 1:19 PM
> To: oasis-member-discuss@lists.oasis-open.org
> Subject: RE: [oasis-member-discuss] Re: RDDL thread

>  
> One comment - there are multiple versions of RDDL and in fact, from
> what this outsider can tell, RDDL is being "superseded" by efforts
> at the W3C in the GRDDL effort.

>  
> In fact, RDDL is no formal standard (though it does seem to be
> attractive as somewhat of a de facto standard). The version published at
> www.rddl.org is actually not the latest proposal for RDDL, but seems
> to be the one that has gotten the more traction.

>  
> Does OASIS care about the status of RDDL if it is going to mandate
> its use? I actually like the concept of prodding TC's to publish
> RDDL documents, but I'd hate to be having to track a moving target....

>  
>     -Gabe
>  
>
> 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

> 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...
>
> 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
> Blog: http://spaces.msn.com/mrgoodner/
>
> 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   [image removed]  ( P )  Pronunciation Key  (p[image
> removed] r-s[image removed] s[image removed] t[image removed] nt, -
> z[image removed] s[image removed] -)
> 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

> _______________________________________________________________________
> Notice:  This email message, together with any attachments, may contain
> information  of  BEA Systems,  Inc.,  its subsidiaries  and  affiliated
> entities,  that may be confidential,  proprietary,  copyrighted  and/or
> legally privileged, and is intended solely for the use of the individual
> or entity named in this message. If you are not the intended recipient,
> and have received this message in error, please immediately return this
> by email and then delete it.


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