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: Membership and Public Review of OASISArtifact Standard Identification Scheme for Metadata


> >Line 216 introduces the possibility that the TC Administrator might
> >         create aliases for some or all existing artifacts.
> >
> >  Please don't[1].
> >
> The intent is to allow a full consistent naming structure (on
> docs.oasis-open.org) even though some content is there already. The
> alternative is to remove support for the old, promised-persistent URIs,
> or to do another domain (documents.oasis-open.org?). I'd say this nmight
> be the best of a set of bad choices.

No, the best choice would be to leave things be and use the ASIS for new (and possibly
currently-in-development) endeavors,

So, I whole-heartedly concur with Norm's admonition.

Please don't.

> >Line 263 abbreviates "requirements"; line 265 abbreviates "specification".
> >
> >  Please don't. The few characters saved pale in comparison to the
> >  confusion caused by abbreviations, not only for non-English
> >  speakers, but also for those of us who have to remember,
> >  "'requirement' is abbreviated, but 'profile' isn't, is that right?
> >  Or is it the other way around?"
> >
> so is "docs.oasis-open.org" OK?  :-)  Good suggestion.

docs.oasis-open.org is just-fine-thank-you-very-much.

Please do not change that. It is already in use. Norm's comments related to the other
abbreviations used as metadata tokens. docs.oasis-open.org is a domain name.
Changing that will only serve to dilute the brand.

> >Line 275 introduces dates of the form "YYYYMMDD".
> >
> >  Can we please the ISO standard YYYY-MM-DD format? And does this mean
> >  that I can't use "23 Feb 2006" as the date on the cover page of my
> >  specification?
> >
> Alas, the hyphen issues strike again. And 23 Feb 2006 is fine by me, but
> the metadata format also needs to be there. Do you have better separator
> character than hyphen to use in artifact names and URIs?

Can we please, please separate the filename gorp from all other expressions of metadata? I would
certainly hope that the expression of a date on a cover-page of a specification could be of the
form that Norm suggests (DD Mon(th) CCYY) . I prefer that form in all expressions as it is
the least likely to be confused.

> >Lines 438 and 439 say that the "stage" is optional for schema and wsdl
> >      artifact types
> >
> >  Why? Where is the rational for this. What makes them different from
> >  catalogs or guidelines or any other type of artifact? If I invent a
> >  new artifact type, do I get to say if the stage is optional? If not,
> >  who does? The TC administrator, I assume, but it isn't stated.
> >
> >  I think it's wrong to make the stage optional for some types and not
> >  others.
> >
> Original motivation, I think, was to allow a single schema namespace URI
> without requiring a change for each developement version of a spec. This
> is existing practices in a number of TCs.

IMO, this is a classic example of where it makes sense to separate out the namespace URI from the
URI of the resource(s) that it represents and why it is considered good practice to have a
namespace document (RDDL) that describes the namespace as opposed to having the schema
or WSDL document at the end of the namespace URI. Please DO keep in mind that there
is not necessarily a 1:1 correspondance between a namespace and a physical schema

However, IMO, it also points out the folly of forcing the metadata to be expressed in the filename.
IMO, the practice adopted by the W3C for providing:
        This version: [dated URI]
                Latest version: [persistent URI]
                Previous version: [dated URI]
is something that OASIS should long ago have adopted as well. If I embed the metadata within the
artifact, yet make it available via some persistent URI (regardless of what its current status is), then
it means that in such cases where ONLY the metadata has changed, that the resource's URI
need not change. This is "A Good Thing(tm)".


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]