[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: Re: fixing 3.1.2.2, picture behaviors
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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC