[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: Re: fixing 3.1.2.2, picture behaviors
Dieter,
Your pseudo-code confirms the sort of mechanism that I expected must be at
work for plugin-browser interfaces: on C2C where the CGM viewer cannot
handle (i.e., some picture behavior other than _self or _replace), the
viewer hands the navigation request plus behavior (TARGET) back to the browser.
I have included your entire message below, let me make a couple of
observations about bits and pieces.
First, in the context of C2C links:
### begin excerpt ###
{
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[...]
### end excerpt ###
To begin, understand that I'm *not* recommending, regarding H2C links (yes,
H2C), that we try to support the use of pic behavior in "#" fragments
instead of the more sensible TARGET attribute. However, the point I'm
trying to make is that there is no technical reason that we could not do
so. If TARGET were default (_self), and there were some behavior like
_parent in the fragment, then here's how it would work. The viewer would
be called; would see that it couldn't handle the navigation request by
itself; and would turn around and call the browser, as in above
pseudo-code, to handle the request.
Technically, it is perfectly possible to use pic behav the "#" fragment in
H2C links. We are making the choice that it is bad practice, and therefore
should be proscribed for H2C links. Which choice I agree with. (One
question I have not completely thought through: are there any scenarios of
non-CGM to CGM links, where non-CGM is *not* HTML, which we are overlooking
and which should be supportable under WebCGM 1.0? I.e., a link sequence
like HTML-to-OTHER-to-CGM?)
Additional comment about above pseudo-code: 'href="linkuri including
fragment, but without pic behavior"'. This presumes our decision to
proscribe the use of "#" fragment, correct?
Okay, where are we? Back to the 3-point summary from yesterday's mail:
Conclusion:
1. deprecate the usage of picture behavior inside the fragment
2. allow for usage of 3rd param also in CGM cases (3.2.2.3, 5th p)
3. Instruct users to use the TARGET statement when doing H2C
There is apparently no objection to implementing this. So now what are the
editorial directives for Dave?
**Do we try to work on some variant of the table that I offered? according
to #3 above, the first column does disappear: links from non-CGM into CGM
use TARGET instead of fragment for picture behavior.
**Or, do we simply try to clarify the language per this long dialog?
**Must edit 3.2.2.5 5th pgph to allow 3rd parameter in C2C case, and
deprecate the fragment.
**Need to edit the examples, per your email of yesterday.
-Lofton.
At 08:52 AM 3/28/01 +0200, Dieter Weidenbrueck wrote:
>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" <<mailto:lofton@rockynet.com>lofton@rockynet.com>
>To: "Dieter" <<mailto:dieter@itedo.com>dieter@itedo.com>
>Cc:
><<mailto:cgmopen-members@lists.oasis-open.org>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>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>http://cgmopen.org/webc
> gm/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:
> <mailto:cgmopen-members-request@lists.oasis-open.org>cgmopen-members-request@lists.oasis-open.org
> >
> >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC