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: RE: NN fragment -- bad news?


Greg,

anything like

<A HREF="JavaScript:ShowCGM('http://some_name/file.cgm#obj1')"> Hypertext
</A>

would require the JavaScript either to be located on the same HTML page or
to be included. I agree that this is usually not a big deal for people who
know what they're doing. However, you know that this is more complicated to
handle in products like FrontPage etc.

If you have a programmed IETM like a parts catalog this is not an issue,
because usually you will use a whole set of JavaScripts anyway. The
intention of this whole URI linking was, however, to simplify the linking
for the occasional user and to get away from the need for programming.

All in all, both ways of controlling a viewer must exist in the future (and
work):
- simple HREF linking for "easy" handling
- viewer control by means of a scripting language for complex cases

The latter requirement should lead to a CGM DOM, which is what we have been
discussing for a while.

Dieter

----- Original Message -----
From: "Lofton Henderson" <lofton@rockynet.com>
To: "Greg Gallant" <GregG@micrografx.com>
Cc: <cgmopen-members@lists.oasis-open.org>
Sent: Tuesday, February 06, 2001 10:46 PM
Subject: RE: RE: NN fragment -- bad news?


> At 12:34 PM 2/6/01 -0600, Greg Gallant wrote:
> > > Netscape's lack of concern about the problem is
> > > more serious now (because 4.73 is affected, as well
> > > as the somewhat shakey new 6.0 release), and I think
> > > we need to attack as energetically it as we did IE.
> >
> >Best of luck here.  They are giving away their product to a captive AOL
> >audience of around 30 million users, few of which could give a hoot about
> >WebCGM.
>
> Interestingly enough, Microsoft actually put their IE project manager onto
> it, working with us, until it was solved (resulting in the BHO).  I think
> the pressure from US Navy and Boeing helped immensely.  I think they won
> some points by being responsive.
>
> Netscape already said, in the Bugzilla dialog, that "Enterprise clients"
> (Boeing, US Navy) were not their principal focus at this time (in
> development of 6.0).  So we tried the SVG connection -- SVG won't work
> either, as its object addressing is based on fragments just like in
> WebCGM.  Chris Lilley has weighed in on it (in Bugzilla dialog), with
> inconclusive results.
>
> At that time, we thought 4.73 was okay and didn't know about 6.0 -- we
were
> trying to diagnose it.  Now that we know the situation, and now that we
> know it affects all NN versions, we need to try to see what we can do in
> the way of either a fix (fix NN, seems unlikely), or workarounds (like the
> BHO).
>
> I'll let others comment on your workaround, below...
>
> > >
> > > At 09:19 AM 2/6/01 +0100, Dieter Weidenbrueck wrote:
> > > > All,
> > > >
> > > > I agree with Greg here. However, we still need to be
> > > > able to insert a simple HREF pointing to an object
> > > > inside a WebCGM file into HTML.  To load a file
> > > > explicitely as described by Greg you would always
> > > > need a javascript.
> >
> >For what it's worth, this is really a non-issue.  All commonly-used
browsers
> >support JavaScript, and the coding difference between a standard HREF and
an
> >HREF that indirects through a script is small:
> >
> ><A HREF="http://some_name/file.cgm"> Hypertext </A>
> >
> >versus
> >
> ><A HREF="JavaScript:ShowCGM('http://some_name/file.cgm')"> Hypertext </A>
> >
> >or
> >
> ><A HREF="#" ONCLICK="ShowCGM('http://some_name/file.cgm')"> Hypertext
</A>
> >
> >Note that the browser "knows" what to do when it sees just the fragment
> >separator in the above, commonly used, HREF syntax.  When you ask the
> >browser developers to mess with how they are currently handling fragments
> >there is a domino effect for code within their product.  They incur a
> >serious Q/A cycle.
> >
> >We recommend that our viewer customers generate links like the above
which
> >directly end up calling our viewer to load a cgm.  Doing so allows them
to
> >take advantage of our internal optimizations.  I don't know of any
> >complaints about the slight adjustment in syntax.
>
> [LH clarification:  this refers to ActiveCGM, not WebCGM]
>
> >-gcg
>



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


Powered by eList eXpress LLC