Re: fixing 3.1.2.2, picture behaviors

[Lofton Henderson <lofton@rockynet.com>]

There's a lot here.  It will be 1-2 days before I can get back to it....

-Lofton.

At 09:44 AM 3/27/01 +0200, you 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