Thanks for your comments (and kind words). To be honest, I wasn't
expecting to spend much more time on this -- I thought I had done the
final version -- but can try to make a few more changes over the next
couple of weeks. More responses below:
jkeane wrote:
> 3.1. Second Bullet - "Lowercase spelling is /recommende//d" /
>
> Why? Some of our groups have grand discussions on camelCase and
> UpperCamel case. e.g LegalXML and OdrXML are official title from their
> charters. Mixed case reads better than legalxm or odrxml. And, hey,
> maybe I am just a case sensitive kind of guy ;-)
>
> I don't see any need for this recommendation and, unless there is
> a cogent technical reason, suggest deleting the thought in the
> final version.
It certainly seems unfair for me to use OdrXML as an example and then
lowercase it, which was not the choice the real OdrXML group made!
I don't have a problem saying that lowercase or mixed case may be used.
I could show examples of both.
> "3.1. General Rules
>
> The following rules apply to all documents:
>
> *
>
> Hyphens /must/ be used as separators of the major portions of a
> file name. Spaces /must not/ be used. Hyphens are /recommended/
> between words within the description and extended description
> portions, though underscores /may/ be used."
>
> Didn't we retire underbars in the the last discussion? With a poll? We
> should either discourage underbars or also be silent on this point.
Well, they are discouraged (hyphens are "recommended"), and hyphens are
mandated between guidelines-dictated parts. I kept this allowance only
because there's no way to parse a filename and find the official
guidelines-dictated parts if hyphens are used within parts, and just in
case, I thought it would be better to at least allow some other
separator if someone cared. I'm inclined to leave this as is, unless
someone objects.
>
> *3.4 "cs* for Committee Specifications" Isn't this acronym a bit
> cryptic? And contrary to the no cryptic acronym policy in the introduction.
True. What would be better -- cttespec? spec? The latter doesn't seem
so bad, and suggests that maybe draft / spec / std would have been
better than draft / cs / oasis. Thoughts? (Sigh.)
> *A. Notices*
> Curiosity: What is the source of the language in this notice? From
> the OASIS lawyer? Are we supposed to have that in all documents?
> Speaking as a lawyer, can the language be simplified?
I would love to have it simplified. In constructing the original SAML
specs, we discovered that all those statements were required to appear
(see the Notices section of
http://www.oasis-open.org/who/intellectualproperty.shtml), and ever
since then, I've been treating them as boilerplate (and that's why
they're in the template). Karl, can you comment on the possibility of
shortening these?
>
> *CLOSURE*
> AND - how can we bring this to closure? Do we vote? Consensus? Formal
> Adoption by the Board? LegalXML has a steering committee next Tuesday
> and I would like to report this is done.
There is no formal process for the "chair community" to decide anything.
I had already made this "submission" to Eduardo Gutentag (TAB chair)
and Karl and asked them to take it forward as appropriate, based on this
community's self-organized manner of lurching forward on the subject.
:-) They would need to tell us what's happened since then.
Eve
--
Eve Maler +1 781 442 3190
Sun Microsystems cell +1 781 354 9441
Web Technologies and Standards eve.maler @ sun.com
----------------------------------------------------------------
To subscribe or unsubscribe from this elist use the subscription
manager: <http://lists.oasis-open.org/ob/adm.pl>
