Re: WebCGM preview

[Lofton Henderson <lofton@rockynet.com>]

At 05:04 PM 5/29/01 +0200, Dieter Weidenbrueck wrote:
>[...]
>Comments:

>1. The wording is a bit confusing:

Tell me about it!!!

>For an object that has a view_context attribute
>- 3.1.2.3 suggests both navigation AND highlight plus a default behavior
>(highlight)
>- 3.2.1.1 suggests navigation only
>This should be made consistent.

I agree.  We have talked to Chris and will delay Second Release for another 
week or so, while we straighten it out.

>The combined navigation and highlighting of course only works if there is a
>body, i.e. if graphical primitives exist.
>Also the last sentence of the view_context para should read
>"The view_context behavior is the default behavior."
>The current language is probably misleading with regard to the highlight
>statement right before the "This is...".

Yes, I noticed the same and it bothered me as well.


>It becomes obvious that the viewer behavior leaves a lot of room for
>interpretation. The requirement "... moves the object into view" for example
>is met in your example, because a shrink-to-fit representation does of
>course show the object. However, this example really doesn't show the
>difference between highlight and view_context.
>IsoView will move the object into view and zoom into the illustration so
>that the object becomes the dominant part in the viewer rectangle.

I want to call attention to a 2nd Release clarification which is already in 
the draft 2nd Release text, and which was discussed several times (and 
finalized, I think, either at the 6/00 Autotrol meeting or the 12/00 DC 
meeting):

The third bullet, at the end of 3.2.1.1, now reads:

"If the object contains neither a view context nor a region attribute, the 
viewer shall move the object into view and indicate
visually that the graphical primitives of the grobject are the target of 
the link. The manner in which the viewer creates the new
display is viewer dependent. The resulting view is a full-picture view, not 
a zoomed view."

Note the new last sentence to this paragraph, clarifying the ambiguity 
which you noted above.

(Note.  I see no problem with offering different behaviors as viewer 
options.  But the viewer has to be capable of the specified behavior, and 
it should be the default, in the absence of user option setting.)


>BTW, we recently decided to use lowercase for all attributes/tag names.
>Throughout the spec almost all possible variants of "view_context",
>"linkuri" etc are used. Will we adjust the spelling in the spec to lowercase
>as well?

Yes, I will work with Dave to make it as consistent as possible.  Note that 
we never had any problem with the "view_context", which is a *value* of the 
object behavior parameter (of the fragment).  But it does get confusing 
because we refer to:

1. "ViewContext" -- as a generic term for the view context concept.
2. "ViewContext" -- as the value of the APS attribute 'type' parameter, 
indicating a view context APS attribute.
3. 'viewcontext' -- as the value of the APS attribute 'type' parameter, 
indicating a view context APS attribute.
4. "view_context" -- as a possible value for the object behavior bit of the 
fragment.

Anyway, we'll sort it out.

-Lofton.