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

 


Help: OASIS Mailing Lists Help | MarkMail Help

cgmo-webcgm message

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


Subject: RE: [cgmo-webcgm] REVIEW: Chapter 1


Lofton,

See my responses inline.

<snip>

>There are several questions of style.  Here are three references that 
>pertain to style rules.  I generally follow, but don't consult them 
>intensively.  Feel free to point out deviations (and note that the OASIS & 
>W3C styles may be contradictory.)
>
>[1] http://www.w3.org/Guide/pubrules
>[2] http://www.w3.org/2001/06/manual/
>[3] http://docs.oasis-open.org/templates/

Thanks for the references.


<snip>

>One preface of my own:  if we have any of this references stuff wrong 
>(e.g., which version of DOM3 Events or DOM2 or ...), then it can get 
>straightened out definitively in the W3C phase (assuming there is one).

Good point.

>>1) Some of the references to W3C Recommendations point to a date-specific
>>version, e.g. DOM Level 3 Core, Xpointer Framework, while others point to
>>the latest version, e.g. SVG 1.1, HTML 4.01. Is there a particular reason
>>for that, or did it just turn out that way?
>
>[**LH**]  I think "just turned out that way".

OK.

>>Should we standardize on one or
>>the other?
>
>[**LH**]  I'm unsure about that.  My general leaning is "no" -- there might

>be cases where you want latest, or cases where you want specific.

I am fine with "no."


<snip>

>Back to 1.3, non-normative references.  I have a mild preference in general

>for "fixed version".  But I might opt differently for different cases, and 
>could be easily convinced.
>
>Thoughts?  Preferences?

I really don't have a preference either way.  I just thought it was odd that
roughly half were done one way, and the other half were done the other way.

>>2) There is inconsistent usage of punctuation at the end of each
reference.
>>All references end with a URL. Most end with a space followed by a period
>>(makes it easy to copy and paste the URL I suppose, although most of these
>>have an anchor element that you can click on to navigate to the
>>destination). Some end with a period immediately after the URL, e.g. HTML
>>4.0.1, while others don't end with a period at all, e.g. UAAG 1.0.
>
>[**LH**]  I'll propose URL-SPACE-PERIOD.  Does that seem okay?

Yes.


>(I have just gotten into the habit of not putting a punctuation or funny 
>character adjacent to the URL, because ...blah...blah...  Especially if the

>printed URL is actually carrying the link as well.)
>
>
>>DOM Level 3 Events - This is now back on the standards track, and the
latest
>>version is a working draft.
>>
>>http://www.w3.org/TR/2007/WD-DOM-Level-3-Events-20071221/
>>
>>Is it appropriate to cite it here? I know that it would definitely not be
>>allowed as a normative reference. If it is not appropriate to cite it,
then
>>we could always replace this with DOM Level 2 Events.
>>
>>http://www.w3.org/TR/DOM-Level-2-Events/
>
>[**LH**]  No strong feeling.  (Benoit did most of our Events research
here.)

As you pointed out, this can be sorted out in the W3C working group.


>>CSS 2.0 - CSS 2.1 is at the candidate recommendation stage.
>>
>>http://www.w3.org/TR/CSS21/
>>
>>As I mentioned above, I'm unsure of the exact rules regarding citing "work
>>in progress" documents as informative references. CSS 2.1 is intended to
>>replace CSS 2.0, so we might want to consider citing CSS 2.1 here if the
>>rules allow it.
>
>[**LH**]  I'm thinking that 2.0 suffices.  Reason:  I think the only thing 
>we take from it is the inheritance model, and we basically imitate that (in

>WebCGM).  Does 2.1 change the model (in which case I'd say "no, stick with 
>2.0")?  Does 2.1 improve the model description (in which case, "yes, ...").

This can also be sorted out in the W3C working group.  As far as I can tell,
the inheritance model is unchanged in CSS 2.1.  Having said that though, the
CSS working group makes it clear that they intend for 2.1 to replace 2.  If
CSS 2.1 advances to REC in a timely manner, I think we should respect the
working group's wishes and cite 2.1 instead of 2.


<snip>

>>If WebCGM is indeed a trademark, shouldn't that be acknowledged in a more
>>prominent place, e.g. the title page, instead of being buried in the
middle
>>of an introductory chapter containing mostly informative material?
Shouldn't
>>the trademark owner be mentioned somewhere, e.g. in the "Notices" section?
>>Maybe this should be an issue thread?
>
>[**LH**]  Here is the history.  When CGM Open Consortium Inc was writing 
>1.0, and making it a W3C Rec, we put the TM there.  Reason:  we didn't want

>someone to coopt it for a product name.
>
>If CGM Open Consortium Inc owned it (pre-OASIS), or co-owned it, then OASIS

>has inherited that.
>
>Bottom line.  I don't know who owns it.  OASIS or W3C or both or 
>neither.  Every time I edit a new version, I look at it, wonder, and move
on.
>
>Do you think we should quietly eliminate it?  Or quietly leave it?  Or...?

Based on the history you presented, I would say that WebCGM is, at a
minimum, an OASIS trademark.  Also see this page.

http://www.oasis-open.org/who/trademark.php

I think we should discuss this further in a telecon or upcoming F2F meeting.


<snip>

>>1.7
>>I find the last sentence awkward for two reasons:
>>
>>1) It contains "specific-industry" which sounds strange to me. The
previous
>>sentence has "industry-specific" which sounds better.
>>
>>2) "... and defined is defined in ...". I stumbled over that one too. One
>>way to fix it would be to change the second "defined" to "described."
>>Another way would be to strike "and defined."
>
>Fixed as follows...
>
>[**LH**]  Rewrite the sentence into the active voice, "Cascading Profiles 
>describes the use of WebCGM as a core profile from which specific 
>industries derive and define their technical profiles."

Good.


<snip>

>>1.10
>>The first sentence, "This subsection ..." is redundant since the chapter
>>defaults at the beginning to an informative chapter.
>
>[**LH**]  By the time I read your comment, I was just thinking... would it 
>be nice to put the normative/informative notation at the start of each 
>first-level section of the chapter, with the inheritance statement 
>"...unless otherwise indicated" applying to subsections (2nd level and 
>below).  I.e., every section N.M would have, "This section and its 
>subsections are {normative | informative} unless otherwise 
>indicated."  Thoughts?

I think that would be OK.  Most chapters are long enough that putting that
sentence at the beginning of each section would not seem too repetitive.


<snip>


>>ISO/JTC1/SC24 - This link now redirects to BSI's home page. I think the
only
>>WWW presence that SC24 currently has is in ISO's "Livelink" system. Lofton
>>and I encountered this a couple of years ago when we were working on
>>Corrigendum 1. The new URL is:
>>
>>http://isotc.iso.org/livelink/livelink.exe?func=ll&objId=327973&objAction=
browse&sort=name
>
>[**LH**]  I'm unsure what you are proposing to do with that.  (In 1.2 there

>is a useful livelink that still seems to work.)

I am proposing we delete the reference to the SC24 Web site, unless someone
finds some useful information on CGM there (I cannot).


>>I didn't find much useful information on CGM there, so we might want to
>>delete the SC24 link.
>
>[**LH**] Okay with me, and we would not use that livelink (just above) at 
>all, right?  I'll check first with Dick Puk, whether there is a useful SC24

>site.

Right, we would not use the above URL at all.  You sent me the short version
in a separate message.

http://www.iso.org/jtc1/sc24/

I just don't see a lot of useful (especially for end users) information
there.


Rob


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