Re: fixing 3.1.2.2, picture behaviors

[Dieter@isodraw.de (Dieter Weidenbrueck)]

Lofton,

 

>linkURI="abc.cgm#picid(myPic,_blank)
> or
> linkURI="abc.cgm#picid(myPic,_parent).
>

we can look at the C2C case alone. A previous H2C link has no influence on this because the target is an expression that is evaluated at the time it will be used.

 

You are basically right, if the linkURIs above are found inside a CGM we have a similar situation. However, in this case the first "browser" getting its hands on the linkURI will be the CGM viewer that read it from the CGM. It will do the following:

 

it will parse the url to detect whether it points to a cgm;

if the linkuri points to a cgm then

{

    the cgm viewer will parse the fragment;

    if it is a valid webcgm fragment then

    {

        it will extract the picture behavior;

        if the picture behavior is not _self and

                                   not _replace and

                                   not the default behavior then

        {

            /* which would all point to a situation where the cgm

             * viewer replaces the currently displayed cgm with

             * another one in its own rectangle

             */

            it will call the HTML browser and pass on the following

            information:

            href="linkuri including fragment, but without pic behavior"

            target="pic behavior"

            /* so the cgm viewer mimics the information that is found

             * within a "normal" href inside HTML.

             */

        }

        else

        {

            /* the cgm viewer can handle the link on its own.

             * Either the target is inside the current cgm or in

             * another one which is going to be displayed inside

             * the current viewer instance.

             */

        }

    }

    else

    {

        /* we would just ignore an invali fragment and still load

         * the cgm without further ado.

         */

    }

}

else

{

    /* if it is not a cgm file the cgm viewer can not do anything about it. So it will pass

     * the link on to the parent browser, if any.

     * NOTE:

     * Here (and in some of the cases above) we have an implicit uncertaincy if the CGM viewer

     * is a standalone application, e.g. a Visual Basic application. If the linkuri specifies a

     * local target, e.g. linkURI="../files/abc.cgm#someObj", the viewer can handle it, but

     * if the URI point to some noteable website, e.g. linkURI="http://www.itedo.com" it

     * will have to pass.

     */

  it will call the HTML browser and pass on the following

  information:

  href="linkuri as is"

  target="content of 3rd param"

}

      

Hope that this "pseudo-code" is understandable, if not please let me know, I also speak Spanish ;-)

 

So the picture behavior inside the fragment can really only be used in one single case, and that is a C2C linkURI that points to another cgm, and the target is the same viewer instance (_self, _replace, default behavior). Which is in fact unimportant as the viewer that is launching the execution of the link is identical to the viewer displaying the result. Internally we parse the linkURI once and then go ahead to download the file and jump to whatever is specified in the fragment.

 

Regarding your question about the previous H2C link I want to add that a target is relative to the current environment. So if you place a linkURI into a cgm containing the target "_parent" you will get different results depending on whether

- the cgm is displayed on a simple web page without frames

- the cgm is displayed on a page with frames

- the cgm is displayed on a page with nested frames.

Once you start executing the links you have to find out where you are and then go ahead.

 

Historical note:

John and I started out to specify a URI as a link, which is the linkURI. We added the fragment (John did most of the initial work here). Inside the fragment we wanted to be able to specify a target. Later we found out that we wanted to specify a target as well when jumping to generic URLs. This is when the 3rd man eh parameter came into live. We should have cancelled the behavior inside the fragment at that time. We did not spend a lot of time on H2C links at that time, at least not with regard to the target question.

 

Hope this answers your question,

 

Dieter

 

BTW: Please apologize if I am a bit more verbose here but I think this is also interesting for the people who do not write a viewer every day to understand.

 

 

 

----- Original Message -----

From: "Lofton Henderson" <lofton@rockynet.com>

To: "Dieter" <dieter@itedo.com>

Cc: <cgmopen-members@lists.oasis-open.org>

Sent: Wednesday, March 28, 2001 6:59 AM

Subject: Re: fixing 3.1.2.2, picture behaviors

> Dieter --
> 
> Thanks 
for your long and careful explanation.  Though I understood much of 
> it already, it did stimulate some thoughts, such as:  I never 
thought much 
> about the OBJECT element and the limitations associated 
with its use (vis 
> a' vis the frame-based picture behaviors).
> 
> Let's cut to your conclusions:
> 
> >Conclusion:
> 
>- deprecate the usage of picture behavior inside the fragment
> 
> I can live with this.  See additional comments below.
> 
> Any objections (anyone)?
> 
> >- allow for usage of 3rd 
param also in CGM cases (3.2.2.3, 5th p)
> 
> We can probably get 
away with this -- though we didn't intend it this way 
> originally, the 
editorial wording "normally should" is vague, and we can 
> correct it 
either way.  Allowing 3rd param doesn't invalidate any existing 
> 
content.  Viewers will have to be updated to be fully capable of new, 
> Rel.2, 1.0 WebCGM.
> 
> Any objections?
> 
> 
>- Instruct users to use the TARGET statement when doing H2C
> 
> 
"..., instead of including picture behavior within the fragment."
> 
> It certainly seems that we should have said this originally.  It 
creates 
> complexity otherwise.
> 
> Okay, but one unanswered 
technical question remains.  What about picture 
> behavior in C2C 
case?  Suppose a HTML document sets up a frameset, and from 
> some 
nested frame links to CGM (e.g., with TARGET="_self").  What about 
> 
picture behaviors, either on the fragment or in 3rd parameter, for a 
> 
subsequent C2C link?  Doesn't this present exactly the same problem as "#" 
> fragment with picture behaviors in H2C link?  I.e., the browser 
knows 
> nothing about the fragment contents, spawns the CGM viewer in the 
correct 
> window/frame (according to TARGET or default _self), and then 
the CGM 
> viewer gets the fragment with the picture behavior, but it's 
too late.
> 
> Doesn't the same problem exist, if there is a C2C 
link, e.g.,
> 
> linkURI="abc.cgm#picid(myPic,_blank)
> 
or
> linkURI="abc.cgm#picid(myPic,_parent).
> 
> The browser 
has already spawned the viewer in some window/frame, so how 
> does the 
viewer change its location in the object hierarchy?
> 
> I don't 
know about plugin interfaces -- maybe there's a way to do it.  From 
> a plugin, through the plugin interface, can you get the same sort of 
> visibility and ability to manipulate the window/frame hierarchy (via 
object 
> properties) as you can from scripting within the HTML, e.g., 
with JavaScript?
> 
> But anyway, the point I'm trying to make is 
that the issues of picture 
> behavior on H2C and C2C really seem to be 
similar, especially if you were 
> to assume (or require) that TARGET must 
be default (_self) if you put pic 
> behav on the "#: fragment in the H2C 
case.
> 
> Comments?  (Anyone.)
> 
> 
-Lofton.
> 
> At 09:44 AM 3/27/01 +0200, Dieter Weidenbrueck 
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
> >
> >
> 
>
> 
>------------------------------------------------------------------
> 
>To unsubscribe from this elist send a message with the single word
> 
>"unsubscribe" in the body to: cgmopen-members-request@lists.oasis-open.org
> 
>