QUESTION: picture behaviors -- corrections and critiques

[Lofton Henderson <lofton@rockynet.com>]

Ref:  http://lists.oasis-open.org/archives/cgmo-webcgm/200509/msg00093.html
Comments:  23
==========

Dieter writes a multi-part comment:

Part 1 (suggestion):
-----
>"'The following Picture Behavior values, except for _replace, are defined 
>per HTML 4.01'. This is incorrect. HTML 4.01 does not define any picture 
>behaviors. It defines keywords, and the definition is different from what 
>we show here in all cases (e.g. using user agent vs. viewer, _parent is 
>differently worded. Suggestion: change first phrase to indicate that 4.01 
>defines keywords that we use as picture behaviors?"

I propose a rewording in the spirit of but slightly different from Dieter's 
proposal, "The following Picture Behavior values, except for _replace, are 
based on @@Frame Target Names@@ of html."

Part 2 (question):
-----
>"Or don't we really define them all here as picture behaviors?"

I'm not sure I understand this part.  We call them picture behaviors.  We 
define the effect when the content type (to load) is CGM and when the 
content type (to load) is HTML.  It is based on HTML 4.01 keywords.  In the 
case of (loading) HTML, I believe the specified effect is the same as 
defined in HTML 4.01 (even if the words don't match precisely to the words 
in HTML 4.01).

Part 3 (critique):
-----
>"Do I have to say, I hate picture behaviors?"

We might have done things differently, if we were starting over.  But given 
5 years of legacy ... I guess we have to make the best of it in the least 
disruptive way.

>"What is it, if they show up in the third param of a linkURI? picture 
>behaviors if the target is a CGM,"

Yes.

>"frame target names if the target is non-CGM?"

When you say "frame target names", I assume that are you including the 
reserved keywords (like "_blank") in "frame target names"?  As I read 
it:  the reserved keywords except _replace, or a name beginning with a-zA-Z.

In summary, ignoring the fact that we might have done things differently if 
we were starting over to design 1.0, I think that the pieces of the 
picBehavior puzzle are accurately enough specified for implementation.  It 
is possible that we could, without making substantive changes, improve the 
presentation by moving tables to different places, splitting / merging 
text, etc.  I would be happy to consider a comprehensive (non-substantive) 
rewrite. But ... without such a proposal, I'm inclined to leave it alone 
and move on to other stuff.

RECOMMENDATION:  none, except the proposed improvement of wording of part 1 
above.

Thoughts?  Proposals?

Regards,
-Lofton.