[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: Re: fixing 3.1.2.2, picture behaviors
At 02:57 PM 3/24/01 +0100, Dieter Weidenbrueck wrote: >[...] >please find my comments in the attached document. I have some comments and questions (indicated by ">>>") to Dieter's comments, which he embedded in the .DOC attachment to his reply: Comments Dieter Weidenbruck: The first column appears to be redundant for the following reason: >>>It was not redundant, mostly because we did not prohibit the full fragment syntax in H2C cases, and specifically the "_replace" behavior made no sense. A link placed inside HTML will be an href. The usual form will be Href="abc.cgm#obj1" TARGET="someTarget" >>>If it was a reference from an 'A' tag, yes. But not from OBJECT tag. See 3.4 ("<OBJECT DATA='xxx.cgm' ...>"). This link will be executed by the non-CGM environment, i.e. the HTML browser. Hence the HTML rules apply. So the HTML browser will only react to target keywords if the target has been specified using TARGET="…". The HTML browser will NOT react to any target that is embedded inside a fragment because it is not its job to examine the URL fragment. >>>So are these picture behaviors allowed on H2C fragments, or are they not allowed? If they are allowed, then it implies that the viewer must somehow communicate with the browser about it. Really, is this any different from a C2C case, that occurs at the end of a H2C2C chain (where the H set up the initial frameset?)? The URL including the fragment will be passed on to the CGM viewer which will already exist at that point in time. So basically the content of row 1 can be deleted and the behavior can be left up to the HTML specification. >>>You mean *column* 1? With regard to WebCGM a hint would be useful, like: When addressing a CGM from outside the CGM environment using an href, the picture behavior keyword will be ignored. In these cases use the TARGET="…" expression defined for the href instead. >>>Does everyone agree that it this what we intended originally? (I can live with this as a clarification, if "yes"). 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? 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"? 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? If we use the third param for all targets, no matter whether within or outside 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. 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 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. >>>Kevin and Don also responded, respectively: Kevin: "I believe our goal, to be consistent with the HTML href element, should be to make the BEHAVIOR attribute of the LINKURI element be the primary mechanism for implementing this functionality." >>>So you are recommending to modify 3.2.2.3, 5th pgh, to allow the 3rd parameter form for CGM targets? Now in WebCGM 1.0? Don: "I agree with Dieter that HTML to CGM is redundant. In fact I don't believe we can define that behavior since it is the Browser that would initiate that action therefore behavior is under control of the Browser." >>>Again, I don't see how this differs from some of the picture behavior options in the case of the C2C part of a H2C2C sequence, where the original H sets up the frameset. -Lofton. ******************* Lofton Henderson 1919 Fourteenth St., #604 Boulder, CO 80302 Phone: 303-449-8728 Email: lofton@rockynet.com *******************
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC