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 3.1.2.2, picture behaviors


Lofton,

please find my comments below:

> 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.
DW: This is correct.

> I have included your entire message below, let me make a couple of
> observations about bits and pieces.
...
>
> 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.
Well, yes and no. We would have to look at the HTML and href definitions to
find out whether this kind of redirection is allowed or intended. It would
leave the first viewer instance (the one that receives the fragment) as an
empty rectangle, but still visible as an OBJECT.

>
> 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?)
The situation arsises whereever a URI can be used, e.g. from within an SVG
file. However, always the same rules regarding the target apply as far as I
know.

> 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?
No, it is just not needed. It would be ignored anyway, so we can as well
omit it. The target however needs to be extracted to become visible to the
browser.

I'm looking forward to see other comments regarding the rest of your email.

Best regards,

Dieter





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


Powered by eList eXpress LLC