Re: fixing 3.1.2.2, picture behaviors

[Lofton Henderson <lofton@rockynet.com>]

Dieter --

Thanks for your long and careful explanation.  Though I understood much of 
it already, it did stimulate some thoughts, such as:  I never thought much 
about the OBJECT element and the limitations associated with its use (vis 
a' vis the frame-based picture behaviors).

Let's cut to your conclusions:

>Conclusion:
>- deprecate the usage of picture behavior inside the fragment

I can live with this.  See additional comments below.

Any objections (anyone)?

>- allow for usage of 3rd param also in CGM cases (3.2.2.3, 5th p)

We can probably get away with this -- though we didn't intend it this way 
originally, the editorial wording "normally should" is vague, and we can 
correct it either way.  Allowing 3rd param doesn't invalidate any existing 
content.  Viewers will have to be updated to be fully capable of new, 
Rel.2, 1.0 WebCGM.

Any objections?

>- Instruct users to use the TARGET statement when doing H2C

"..., instead of including picture behavior within the fragment."

It certainly seems that we should have said this originally.  It creates 
complexity otherwise.

Okay, but one unanswered technical question remains.  What about picture 
behavior in C2C case?  Suppose a HTML document sets up a frameset, and from 
some nested frame links to CGM (e.g., with TARGET="_self").  What about 
picture behaviors, either on the fragment or in 3rd parameter, for a 
subsequent C2C link?  Doesn't this present exactly the same problem as "#" 
fragment with picture behaviors in H2C link?  I.e., the browser knows 
nothing about the fragment contents, spawns the CGM viewer in the correct 
window/frame (according to TARGET or default _self), and then the CGM 
viewer gets the fragment with the picture behavior, but it's too late.

Doesn't the same problem exist, if there is a C2C link, e.g.,

linkURI="abc.cgm#picid(myPic,_blank)
or
linkURI="abc.cgm#picid(myPic,_parent).

The browser has already spawned the viewer in some window/frame, so how 
does the viewer change its location in the object hierarchy?

I don't know about plugin interfaces -- maybe there's a way to do it.  From 
a plugin, through the plugin interface, can you get the same sort of 
visibility and ability to manipulate the window/frame hierarchy (via object 
properties) as you can from scripting within the HTML, e.g., with JavaScript?

But anyway, the point I'm trying to make is that the issues of picture 
behavior on H2C and C2C really seem to be similar, especially if you were 
to assume (or require) that TARGET must be default (_self) if you put pic 
behav on the "#: fragment in the H2C case.

Comments?  (Anyone.)

-Lofton.

At 09:44 AM 3/27/01 +0200, Dieter Weidenbrueck wrote:
>Lofton,
>
>let me first state that I believe we can only clarify the situation up to a
>certain point but not remove the ambiguity completely.
>
>So let me try:
>
>Whatever URI is used within the scope of an HTML document depends on the
>rules of HTML, no matter whether it appears inside an HREF or an OBJECT tag.
>Example 1:
>href="abc.cgm#somefragment"
>The browser will execute this href by detecting the correct MIME type, and
>then either handling this MIME type itself (e.g. for HTML, GIF, JPEG
>destinations) or it will launch an appropriate viewer registered for this
>MIME type. If nothing else is specified the destination document (in this
>case abc.cgm) will replace the entire content of the window that contained
>the HTML with the href. The process that will handle the MIME type is
>supposed to examine the fragment and handle accordingly. For HTML, this
>would be the web browser, for CGM the viewer would parse the fragment.
>Example 2:
>href="abc.cgm#somefragment" TARGET="_blank"
>Same as above, except for that the browser will launch the viewer inside a
>new window. This is because the TARGET specification if part of the HTML
>syntax. Again, the browser handling the href will not care for the
>fragment's contents unless it can handle the MIME type itself.
>Example 3:
><OBJECT DATA='abc.cgm#somefragment' ...>
>The browser will create the object and pass on the data property. The object
>will be created where it has been defined, i.e. somewhere in the middle of
>the HTML page. NOTE: It is not possible to specify a target within an OBJECT
>tag, the OBJECT will be created whereever it appears in the HTML flow.
>
>For all examples we can identify the following sequence:
>- The URL including the fragment is read by the HTML browser
>- The browser detects that it can not handle the MIME type and launches a
>CGM viewer
>- The CGM viewer is launched at the location specified on the HTML side, NOT
>at a location potentially specified in a fragment.
>
>Example:
>href="abc.cgm#picID(myPic,_blank)"
>or
><OBJECT DATA="abc.cgm#picID(myPic,_blank)"
>
>In both cases the viewer will be created first, and then it will see the
>URL. So the href will replace the content of the current HTML window with
>the viewer, The OBJECT tag will be created within the HTML flow somewhere on
>the page.
>Without a fragment the intent is unambiguous: The cgm file will be displayed
>inside the viewer wherever it has been created.
>Now if a fragment with a target has been specified we have an undefined
>situation. The _blank statement suggests that the CGM viewer displays the
>CGM in a new empty window. So we have the CGM viewer that has been created
>by the HTML browser, and before it starts displaying the cgm it will open a
>new window and display it there?
>Therefore in my opinion the specification of a target as a part of the
>fragment is not applicable in the case of H2C.
>
>So I would enhance the suggestion in my last email as follows:
>"When addressing a CGM from outside the CGM environment using a URI, the
>picture behavior keyword will be ignored. In these cases use the TARGET="."
>expression defined for the href instead."
>
>
> >Other things to look out for:
> >We continue to have a redundancy because there are two places where one can
> >specify a target:
> >-       the picture behavior in the fragment
> >-       the third (target) parameter of the linkURI
>  >>>Does anyone recall the reason for this?
>
>No, unfortunately not. John and I were thinking about the C2C and C2H cases
>most of the time. The OBJECT tag and the H2C cases have been added at the
>very end, and this issue obviously fell through the cracks.
>
> >Suggestions:
> >Once we go to a 1-picture WebCGM the full fragment will no longer be needed
> >because the picID and picName will no longer be used. So from there on only
> >the behavior would lead to a long fragment.
>
>  >>>You mean, "only the *object* behavior"?
>No in this case the picture behavior. There are two pieces of information
>that belong to the picture in the long form of the fragment: the
>identification (id or seqNo) and the picture behavior. In a 1-picture WebCGM
>the identification part would become obsolete, so the picture behavior would
>be the only reason why the long form would still be needed. If default
>picture behavior is used, the short form (only the object stuff) would
>suffice.
>
> >To avoid this and to harmonize we should in general specify the target in
> >the third param of the linkURI, i.e. separate from the fragment. We can
> >still leave the current fragment syntax in place, however, there is so much
> >confusion already that there will be a change in viewer behavior as soon as
> >we implement the recommendations above.
>
>  >>>I don't understand.  Do you mean implement, "ignore picture behavior
>parts of fragment in H2C" links?
>Yes. Once the viewer sees this picture behavior part for the first time it
>(the viewer) has been created already at the location where it shall display
>the cgm.
>
>YIf we use the third param for all targets, no matter whether within or
>Youtside of CGM we are consistent with the href syntax.
>
>  >>>As I read 3.2.2.3, the 3rd param is *required* for non-CGM.  But
>paragraph 5 of 3.2.2.3 suggests says that the fragment is used for CGM
>targets, and in fact a Release 2 editorial correction is changing "should
>normally" to "shall".  It is clear that we did not intend 3rd parameter to
>be used in these cases, regardless of what we think now.
>The intention was to specify the 3rd param where needed. If it stays empty
>the default behavior of the HTML browser will be applied (replace in current
>container of the viewer).
>You are right, the intention was to use the fragment to specify targets in
>CGM, and the 3rd param to specify targets outside of CGM. What we didn't
>think about was the fact that the uri fragment including a picture behavior
>may appear outside of the CGM itself, and there the behavior is defined in a
>different way.
>
>Let me comment on the examples in the recommendation:
>3.1.3.2 Example 1
>Correct.
>If we deprecate the target in the fragment and use the third parameter
>instead the linkuri would look different:
>First string of linkuri:
>http://cgmopen.org/webcgm/engine.cgm#pictid(top).id(cyl-hd-t,highlight)
>Second string of linkuri:
>
>Third param of linkuri:
>_blank
>
>3.1.3.3 Example 2
>The first sentence of the description should be changed as follows:
>When used as the URL in an OBJECT element in HTML, this example displays the
>CGM inside a rectangle defined by the width and height parameters of the
>OBJECT tag, displaying the whole of "top" with the pump highlighted.
>
>3.1.3.4 Example 3
>This example is ambiguous because it does not state where the URI resides.
>If it resides inside the CGM it is ok as long as we don't deprecate the
>target inside the fragment. If it resides outside of the CGM the href needs
>to be changed as follows:
>http://cgmopen.org/webcgm/engine.cgm#pictseqno(5).id(dist-i,view_context)
>TARGET="topframe"
>
>3.1.3.5 Example 4
>Same comments as in 3.1.3.4
>
>3.1.3.6 Example 5
>Correct
>
>3.1.3.7 Example 6
>Correct
>
>3.1.3.8
>Correct
>
>
> >If we continue to allow for both ways we need to clarify the wording a bit.
>
>  >>>Prohibiting "#" fragment and requiring 3rd parameter seems like a
>significant functional change.  I don't think we can consider it for
>Release 2 of WebCGM 1.0.  (On the other hand, it might be possible to allow
>3rd parameter form, and even deprecate the "#" fragment, but making a
>different editorial fix to last sentence of 5th pgph 3.2.2.3, than the one
>currently specified.).
>I agree with this approach. We should also add some wording that any picture
>behavior specified in a fragment outside of the CGM will be ignored (see
>above).
>
>  >>>I guess my preference is clarify but not change, even if we would all
>prefer always the 3rd parameter form -- the current stuff works and does
>not invalidate existing implementations.
>Completely agree.
>
>Conclusion:
>- deprecate the usage of picture behavior inside the fragment
>- allow for usage of 3rd param also in CGM cases (3.2.2.3, 5th p)
>- Instruct users to use the TARGET statement when doing H2C
>
>Comments?
>
>Dieter
>
>
>
>------------------------------------------------------------------
>To unsubscribe from this elist send a message with the single word
>"unsubscribe" in the body to: cgmopen-members-request@lists.oasis-open.org