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] Chapter 3 review


Rob,

Thanks for a careful and thorough review!  To save time, I'm taking the 
shortcut of embedding all my answers in your message.  Everything is 
editorial and "Done" (i.e., I fixed per your comments, if not previously), 
unless it says "QUESTION n" (n=1..8).

It is probably worth our while to briefly visit those QUESTIONs.

At 05:13 PM 9/30/2005 -0600, Robert Orosz wrote:
>I haven't had a chance yet to read Dieter's and Ulrich's comments, so some
>of mine might duplicate what has already been said. I used Amaya to edit the
>HTML and flagged my changes with the .editorial style. I'll summarize and
>make additional comments in the body of this message.

Okay, thanks.  I'll go through them one-by-one below.


>Section 3.1.1.1
>
>I removed "Objects" from the second sentence.  It is given a different
>definition later in this chapter.

Done.


>RFC 3986 was referred to as RFC-3986 (hyphen) and RFC3986 (run together) in
>this chapter.  I prefer "RFC 3986" (space); this is the style used in the
>RFCs themselves.

Done (everywhere).


>Section 3.1.1.3
>
>This section is very difficult to read.  I had to read it several times to
>digest it.

I agree.  But I suggest to minimize changes, to avoid breaking anything.


>'xcfurl' wasn't mentioned in the first sentence.  Is this a bug or a
>feature?  I assume it is a bug.

Bug, fixed.

>Rule number 2 does only one thing, it eliminates NUL from the character
>repertoire.  T.14.5 already eliminates all of the C0 control characters
>except for NUL, so applying this rule only serves to eliminate NUL.  T.14.5
>could be modified to prohibit NUL, and this rule would be unnecessary.
>Interestingly, neither T.14.5 or rule number 2 say anything about the C1
>control characters, they are allowed (with presumably undefined effects) the
>way this is currently written.
>
>Rule 3 -  objname, removed #x09, #x0a, and #x0d from the whitespace
>definition, they are disallowed by T.14.5

According to our better understanding and clarification of T.14.5, I think 
the best solution is this rewording, which also prohibits embedded "bad" 
whitespace:  "shall not contain (leading, trailing, or embedded any of the 
whitespace characters #x09, #x0a, or #x0d, and shall not contain any 
leading or trailing blanks (#x20);"

QUESTION 1.  okay?


>Rule 3 - picid, contains this: ".... further restrictions: as objid for any
>picid value occurrences within a fragment ...."  Isn't the whole point of
>this section to define the character repertoire of the WebCGM fragment?
>Shouldn't this be worded identically to the "objid" part with the exception
>of the WebCGM element (Begin Picture versus Begin APS) that it corresponds
>to?

Hmmm... I see your point.  The mention of the repertoire of picture id for 
the WebCGM instance itself (as opposed to the more restrictive fragment), 
can perhaps be handled by removing that bit from the 3rd bullet, but 
keeping the reference to the last paragraph of the section that explains 
the point.

QUESTION 2.  Does the same point pertain to objid, about richer/leaner 
repertoire?  I.e., is the repertoire allowable in the apsid parameter of a 
BegAPS element richer than the repertoire allowable in the fragment syntax?


>See highlighted changes in the last two paragraphs.

Done.


>Section 3.1.1.4
>
>See highlighted changes.

Done.


>Section 3.1.1.5
>
>See highlighted change.

Done.


>Section 3.1.2 first paragraph.
>
>Summary is at the end of this subsection.
>
>Section 3.1.2.2
>
>In the middle of this section is the following statement: "CGM viewers shall
>ignore picture behavior specifications in URI fragments which are part of
>links from non-CGM content."  I'm curious, how does the CGM viewer know the
>source of a link?

Good question.  I don't know the answer.  What would happen is probably 
something like this:  a viewer control/plugin is fired up to display the 
CGM specified in the HTML-to-CGM link.  If the HTML contains the behavior 
in the 'target' attribute of the 'a' element, it does all the implied 
window management and starts the viewer.  It gets a fragment.  If the 
fragment contains a picBehavior part, then the viewer would immediately be 
faced with some potential windowing operation, like opening a new window 
(_blank).  I can see what the original wording is trying to avoid, but 
don't know if we're saying it best.  (And I haven't programmed this part of 
a viewer -- the control/plugin interface and window management.)

QUESTION 3.  Can we say better, what we're trying to say here?


>Section 3.1.2.4.1
>
>See highlighted changes.

Done.


>Section 3.1.2.4.2
>
>See highlighted change.

Done.


>Section 3.1.2.6
>
>See highlighted change.

Done.


>Section 3.1.2.7
>
>See highlighted change.

Done.


>Summary table, CGM-to-CGM row, picBehavior column, has "deprecated: picTerm
>...".  If this is deprecated, shouldn't it be removed from the table?

Actually, "deprecated" is editorial error.  We decided "discouraged", and 
that is what 3.2.2.3 says, to avoid the specific conformance meanings of 
deprecated.  The box now says:  "preferred: 3rd parameter of 'linkuri' 
[ref];discouraged: picTerm of URI fragment in 1st parameter (ref)"

>Also,
>the link navigates to linkuri, just like the "preferred" link.

I fixed the links, each to point to its respective paragraph (the two 
paragraphs before the example in 3.2.2.3.)


>Section 3.2.1.1
>
>See highlighted changes in the first paragraph.

All fixed.

>APSA type is case-sensitive,
>right?

Yes, I fixed this so that the "g" of "grobject" is not the first letter of 
the sentence.  (I don't like sentences that start with a lower case letter.)


>See highlighted changes in the example paragraph in the middle of this
>section.  Also this paragraph says "... the event will be "passed on for
>hyperlink processing." ...." and then goes on to give a specific example
>without mentioning which event we are talking about.  Judging from the
>description, I'd say it is a click event.

I'd say so.  The whole "Example" is a little sloppy about that.  So I'm 
inclined to leave it as is (but would accept a careful rewrite that 
qualified the event type everywhere that it needed to be clarified.)

QUESTION 5.  Okay?


>There are a couple more highlighted changes in this section.

Got 'em, thanks.


>Section 3.2.1.2
>
>See highlighted change.

Done.


>Section 3.2.1.4
>
>See highlighted change.

Done.


>Section 3.2.1.5
>
>See highlighted change.

Done.


>Section 3.2.2.1
>
>See highlighted change.

Done.


>Section 3.2.2.3
>
>See highlighted changes in the third, fourth, and fifth paragraphs.

Done, done, and done.


>I do not understand the second bullet item in the example.  How can a
>CGM-to-HTML link contain a WebCGM fragment?

It was bogus.  Whole example was rewritten, see:
http://lists.oasis-open.org/archives/cgmo-webcgm/200509/msg00125.html


>Section 3.2.2.6
>
>See highlighted change.

Done.


>Section 3.2.2.9
>
>A 'layer' cannot be a "descendant object" can it?

No.  Before we remove it, let's be sure that doesn't break the inheritance 
of visibility from Picture to 'layer'.  Recall that we added (to DOM and 
XCF) a pictureVisibility thingy, and the inheritance model of 5.4 
recognizes Picture as the root of the inheritance tree.

QUESTION 6.  Will someone check all of this and see if it is safe to remove 
'layer' here?


>Section 3.2.2.10
>
>Same comment on layer as above.

Same QUESTION.

>Neither this section or the previous
>section gives a description of what the value "inherit" means.  The values
>of "off" and "on" are intuitively obvious, but what about "inherit"?  In
>fact, I could not find a description of this anywhere in Chapter 3.

It is in chapter 5.4.  I linked each occurrence of "inherited" to 5.4.


>Section 3.3
>
>See highlighted change in the comment section of the DTD.

Done.


>The very last link in this section, 3.2.2.10, apparently targets a
>non-existent anchor.  Nothing happened when I clicked on it.

Fixed.


>Section 3.4
>
>See highlighted changes.
>
>Changed script type in the example to "application/ecmascript."  The
>"text/ecmascript" MIME type is deprecated.

Done.

QUESTION 7.  Benoit, do you agree (you authored the example)?


>Added space characters around the "|" character for clarity.

Done.


>The viewport paragraph mentions "the IT attribute."  I do not know what this
>is.  I could not find such an attribute in the HTML 4.01 Specification.

Hmmm... I don't know what this is either, and it has apparently been around 
for a long time.

QUESTION 8.  any ideas, anyone?


>The mapping paragraph is a bit terse.  It defines "Fit" and then "Fill" and
>then goes into the default values without discussing halign or valign.

I guess we were relying on the figures.  But figures are non-normative.  I 
have added an editorial note to generate some words about halign and valign.

Thanks,
-Lofton.




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