OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

cgmopen-members message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]

Subject: Re: fixing, picture behaviors

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


At 09:44 AM 3/27/01 +0200, you wrote:
>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:
>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.
><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
> >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, the 3rd param is *required* for non-CGM.  But
>paragraph 5 of 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:
> Example 1
>If we deprecate the target in the fragment and use the third parameter
>instead the linkuri would look different:
>First string of linkuri:
>Second string of linkuri:
>Third param of linkuri:
> 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.
> 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:
> Example 4
>Same comments as in
> Example 5
> Example 6
> >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, 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
>  >>>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.
>- deprecate the usage of picture behavior inside the fragment
>- allow for usage of 3rd param also in CGM cases (, 5th p)
>- Instruct users to use the TARGET statement when doing H2C

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]

Powered by eList eXpress LLC