RE: [cgmo-webcgm] WebCGM and the <object> tag

["Dieter Weidenbrueck" <dieter@itedo.com>]

Lofton,

please see my comments inline.

At 04:10 PM 12/7/2004 +0100, Dieter Weidenbrueck wrote:
>so do you want to prohibit all the other ways to "reference" a WebCGM from
>HTML?

It is not possible for us to mandate what is in HTML content, unless we 
believe that we are going to do limited validation of HTML instances.  On 
the other hand, it is possible for us to foster interoperability by 
specifying a single standard way to phrase such references.  That is what 
WebCGM now does.
DW: By using a fragment URI syntax we are already specifying what needs
to be in HTML content. In addition, we are now introducing new ways of
"referencing" a WebCGM, e.g. in DOM calls.
So there _is_ more than one legal and intended way to bring up a WebCGM
in a viewer, it's not only the OBJECT tag alone. This needs to be specified
somewhere. 


The specification in WebCGM 1.0 is clear and unambiguous, and was worked 
out in consultation with leading HTML experts, as reflecting the best 
standard way to combine the two standards (HTML and WebCGM).
DW: So what does "reference" stand for then?
I am not disputing the value of the spec per se in this context, we only
may want to clarify the different use cases. If we don't, that's fine
with me, there is an implicit semantic connected to the other methods
(URI with fragment and DOM calls).


This dialog supports my concern about interoperability.  Some CGMO vendors 
support what's in WebCGM 1.0, some support another scheme.  Where's the 
interoperability there?  If all supported *at least* the specification in 
WebCGM 1.0, then the same content package of HTML + WebCGM could work on 
different browser + viewer combinations.  Is that not a good goal?  (It's 
why WebCGM 1.0 is written the way it is -- this was discussed and 
deliberated 5 years ago.)
DW: My recollection is that IE was not in a state that the param could be
used when WebCGM 1.0 was written. At that time we did a lot of work to
make things work _at_all_, hence the BHO. The src parameter was probably
the only choice at that time, and it was an oversight that the param
never got implemented over time.
It's always easy to point at implementations, however, when we (ITEDO)
implemented fragments, we were happy to get it to work at all at that time,
and still up to today IE is not behaving as it should, making the life
of the software vendors a cumbersome one.

Regards,
Dieter