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


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.

>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:
_blank 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:
TARGET="topframe" Example 4
Same comments as in Example 5
Correct 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