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


Hi Robert,

Good catch on "application/ecmascript" instead of
"text/ecmascript".

This is a change that should be made everywhere (i.e., spec and
testsuite :|

-- 
 Benoit   mailto:benoit@itedo.com


Friday, September 30, 2005, 7:13:03 PM, Robert wrote:

RO> All,

RO> I haven't had a chance yet to read Dieter's and Ulrich's comments, so some
RO> of mine might duplicate what has already been said. I used Amaya to edit the
RO> HTML and flagged my changes with the .editorial style. I'll summarize and
RO> make additional comments in the body of this message.

RO> Section 3.1.1.1

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

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

RO> Section 3.1.1.3

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

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

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

RO> Rule 3 -  objname, removed #x09, #x0a, and #x0d from the whitespace
RO> definition, they are disallowed by T.14.5

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

RO> See highlighted changes in the last two paragraphs.

RO> Section 3.1.1.4

RO> See highlighted changes.

RO> Section 3.1.1.5

RO> See highlighted change.

RO> Section 3.1.2 first paragraph.

RO> Summary is at the end of this subsection.

RO> Section 3.1.2.2

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

RO> Section 3.1.2.4.1

RO> See highlighted changes.

RO> Section 3.1.2.4.2

RO> See highlighted change.

RO> Section 3.1.2.6

RO> See highlighted change.

RO> Section 3.1.2.7

RO> See highlighted change.

RO> Summary table, CGM-to-CGM row, picBehavior column, has "deprecated: picTerm
RO> ...".  If this is deprecated, shouldn't it be removed from the table?  Also,
RO> the link navigates to linkuri, just like the "preferred" link.

RO> Section 3.2.1.1

RO> See highlighted changes in the first paragraph. APSA type is case-sensitive,
RO> right?

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

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

RO> Section 3.2.1.2

RO> See highlighted change.

RO> Section 3.2.1.4

RO> See highlighted change.

RO> Section 3.2.1.5

RO> See highlighted change.

RO> Section 3.2.2.1

RO> See highlighted change.

RO> Section 3.2.2.3

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

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

RO> Section 3.2.2.6

RO> See highlighted change.

RO> Section 3.2.2.9

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

RO> Section 3.2.2.10

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

RO> Section 3.3

RO> See highlighted change in the comment section of the DTD.

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

RO> Section 3.4

RO> See highlighted changes.

RO> Changed script type in the example to "application/ecmascript."  The
RO> "text/ecmascript" MIME type is deprecated.

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

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

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


RO> Rob


RO>  <<WebCGM20-IC_review.html>> 





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