RE: [cgmo-webcgm] Chapter 3 review

[Robert Orosz <roboro@AUTO-TROL.com>]

Lofton,

We agreed to defer discussion of this until the next telecon, since you had
to leave early this morning.

Here are my answers to your questions 1-8.

1) Now that I understand T.14.5, yes, your new wording is fine.

2) Yes, you are absolutely correct.  The identifier parameter of both the
Begin Picture and Begin APS elements is of type SF, so T.14.5 applies to
both elements (this is also pointed out in section 9.5.4.6 of CGM99).  The
first bullet in the third rule of 3.1.1.3 applies the XML name rule to
objid.  This rule places restrictions on the overall character repertoire,
i.e. it cannot be any Unicode character.  Therefore, there is the potential
for a Begin APS identifier in a WebCGM 2.0 file to contain a character that
is not allowed in a WebCGM URI fragment.  However, there is a wrinkle :-(.

Section 3.3 (Content Model) contains this in the DTD.

<!ATTLIST grobject
  id           ID         #REQUIRED
...

and the same id attribute declaration is present for para, subpara, etc.  An
attribute type of ID in XML must conform to the XML name rule.

Now, here is the wrinkle.  Section 3.3 is labeled as informative
(non-normative).  WebCGM 1.0 Second Release did not apply the "normative" or
"informative" label to individual chapters and subsections, so the entire
specification including Section 3.3 is taken to be normative.  The scenario
that I describe above is not possible in a valid WebCGM 1.0 file because the
Begin APS identifier parameter in the WebCGM 1.0 file must conform to the
XML name rule.  MetaCheck in fact, will flag a WebCGM 1.0 2nd Edition
profile violation if it encounters a Begin APS id in a WebCGM 1.0 file that
does not conform to the XML name rule.  An easy way to check this for anyone
that has MetaCheck, is to generate a WebCGM 1.0 file containing a APS with a
digit as the first character in the APS identifier.

I assume that the labeling of Section 3.3 as informative is an editorial
glitch; i.e. the Editor did not fully think through the ramifications before
typing that sentence.  If so, I apologize for not catching it in my Chapter
3 review.  We can fix the editorial error and there is no possibility for a
Begin APS id in a WebCGM 2.0 file to contain characters not allowed in the
WebCGM URI fragment just like the WebCGM 1.0 case.  The first bullet in rule
3 of section 3.1.1.3 becomes redundant like it was in WebCGM 1.0.  A little
redundancy here and there doesn't hurt.

If the labeling of Section 3.3 as informative is not an editorial glitch,
then this can be handled by changing the wording of the last paragraph of
3.1.1.3.  Basically, change occurrences of "picid" to "objid and picid" and
massage the surrounding text appropriately.

3) I do not have improved wording for this.  I raised the question because
the current wording "CGM viewers shall ..." sounds to me like a conformance
requirement being placed on the viewer.  I do not know the answer, and I too
have never programmed that part of a viewer before.  If the viewer cannot
determine the source of a link, then that sentence should be deleted.

4) ???  I don't see a question 4, at least not between 3 and 5.

5) Yes, it is fine to leave it as is.  A "careful rewrite" would take more
effort than it is worth at this stage.

6) I would prefer that someone more familiar with the DOM that I am, answer
that one.

7) Here is the URL for the official text media types recognized by the
Internet Assigned Numbers Authority (IANA).

http://www.iana.org/assignments/media-types/text/

And here is the IANA list of official application media types.

http://www.iana.org/assignments/media-types/application/

The RFC behind this change is not yet published (it is in the RFC Editor's
queue).  However, once IANA publishes the media type, it is official.

8) WebCGM 1.0 says "DATA".  There is a data attribute in HTML, so I think
that is what should be here.


Rob


-----Original Message-----
From: Lofton Henderson [mailto:lofton@rockynet.com]
Sent: Tuesday, October 04, 2005 7:08 PM
To: Robert Orosz; cgmo-webcgm@lists.oasis-open.org
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.