OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

cgmo-webcgm message

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


Subject: RE: [cgmo-webcgm] <object> interoperability issue


Answering: "I'm curious after reading that explanation why a test that
uses only the 'data' attribute, and no PARAMs, should fail."

All the ActiveX implementation I've worked with use DoPropExchange. This
functional is called early in the initialization process. It's used to
receive/send properties to and from the ActiveX. WebCGM implementations,
most likely use DoPropExchange to retrieve PARAM values. Note that
DoPropExchange is called regardless if any PARAM values are specified.
You can't query IE to find out which PARAM values are set. Instead MS
provides a set of macros: PX_String( propExchangeInstance, "param name
here", variableToStoreData, defaultValueHere) used on all possible
properties (regardless if present or not).

The limitation in IE is: as soon as you have 'data' on the object tag,
those macros can give you garbage data. That's why a test with 'data'
only can fail.

Hope this helps.
Benoit

-----Original Message-----
From: Lofton Henderson [mailto:lofton@rockynet.com] 
Sent: Monday, June 14, 2010 3:15 PM
To: cgmo-webcgm@lists.oasis-open.org
Subject: RE: [cgmo-webcgm] <object> interoperability issue

Benoit, All --

Thanks for the MS feedback.  The MS technical explanation seems clear.
I 
know it doesn't ultimately matter, but I'm curious after reading that 
explanation why a test that uses only the 'data' attribute, and no
PARAMs, 
should fail.

That detail aside, the real issue is the choice that you indicate.  The 
best solution would be a change to WebCGM, to make it officially valid
what 
two implementations already do (pass a 'src' <param>).  Such a change
would 
not change the metafile definition, nor the DOM/XCF definitions.  It
would 
add one viewer conformance requirement.

Although it looks like an erratum, it might be considered substantive 
because it affects viewer conformance requirements (even tho' it adds no

new functionality.)  So it would require a small (about 1 paragraph) 2.2

upgrade.  (To be continued...here and 6/30 telecon)

What about workarounds -- part 2 of the investigation?  Is there any way
in 
one's ActiveX control code to get 'data' and <param> values other than
as 
described by MS in your message?  Failing that, is it possible to
rephrase 
the example in 3.4 to use the DOM to capture the load event, i.e., a 
work-around to avoid using the onload param, such as we do in existing
tests?

-Lofton.

p.s.  Is anyone involved with the W3C HTML5 project?  The html5 <object>

element is unchanged in allowing 'data' attribute together with <param> 
child elements.  It might be useful input that the biggest browser
doesn't 
support that.

At 09:16 AM 6/14/2010 -0400, Bezaire, Benoit wrote:
>My understanding is the same; I initially tried to simplify the issue
by
>saying that using PARAMs and data together isn't supported by IE. Query
>or not, to me that's relatively minor. Bottom line, the spec describes
a
>practice that is not officially supported by IE. Either WebCGM
>implementations have to change or the spec has to change.
>
>The technical explanation from Microsoft:
>"As you might have already found out experimentally, the current IE
>design does not allow an ActiveX control to be initialized by values
>coming from both the PARAM tag and the data attribute.  You can use
>either the PARAM tag or the data attribute one at a time, but will not
>be able to use both.  When IE instantiates the ActiveX control via the
>OBJECT tag, it will look to see if there are any PARAM values and call
>the control's IPersistProeprtyBag implementation to pass in the data.
>If no PARAM tag is used, then it will next look at the OBJECT tag's
data
>attribute.  If one is present it will call the control's
IPersistMoniker
>implementation to pass the data in an IMonkier form.  The control can
>then call IMoniker::GetDisplayName to get the value.  As you can see
>from this implementation, you will not be able to use both the PARAM
tag
>and the data attribute simultaneously."
>
>Benoit
>
>-----Original Message-----
>From: Lofton Henderson [mailto:lofton@rockynet.com]
>Sent: Friday, June 11, 2010 6:52 PM
>To: Bezaire, Benoit; cgmo-webcgm@lists.oasis-open.org
>Subject: RE: [cgmo-webcgm] <object> interoperability issue
>
>At 03:13 PM 6/11/2010 -0400, Bezaire, Benoit wrote:
> >Here is my sample attached.
>
>Thanks.
>
>
> >You will notice that 'data' is used, but there are no <PARAM>s. Yet
the
> >problem exist since a typical windows application will query for the
> >PARAMs using DoPropExchange regardless if they are specified or not.
>
>It sounds like your understanding of the problem has evolved somewhat.
>So
>is it the "query for the PARAMs", even if it is none is present, that
>causes the problem?  Earlier you wrote about the need for both 'data'
>and
>PARAM to be present:
>
> >...Our implementation (COleControl ActiveX) is passed in corrupted
data
>
> >when both the 'data' attribute is specified on the <object> tag and
>when
> ><PARAM> elements are also specified.
> >
> >According to Microsoft, HTML 4 doesn't state that an implementation
(of
>
> >HTML) has to pass all values ('data' attribute, <PARAM>s)
>simultaneously
> >to the ActiveX. Either 'data' without <PARAM> is used; or <PARAM>s
>without
> >the 'data' attribute is used.
>
>FWIW, I modified your sample.html slightly, so that the <object> sits
>directly in the table in place of the div/divTag stuff.  Your old beta
6
>
>showed the cube fine, whereas old beta 6 crashed on your original
>sample.html code (w/ div/divTag scheme).  It escapes me, why that bit
of
>
>extra script execution matters before the <object> element gets
>processed.
>
>Ugh...
>
>It is hard to believe that this has not become a critical problem for
>MS.  One would think it quite common to use <object>'s 'data' attribute
>with child <param> elements.
>
>-Lofton.
>
>
>
> >-----Original Message-----
> >From: Lofton Henderson [mailto:lofton@rockynet.com]
> >Sent: Friday, June 11, 2010 1:09 PM
> >To: cgmo-webcgm@lists.oasis-open.org
> >Subject: [cgmo-webcgm] <object> interoperability issue
> >
> >Implementors (et al) --
> >
> >Stuart volunteered when I asked for a straightforward test case of
> ><object
> >data=>/<param>:  "Volunteer? (To turn it into a simple, minimal
>complete
> >test case of the 3.4 Example?)"
> >
> >I decided to modify his test to make the simplest possible <object>
>test
> >case:  one <object> element referencing a CGM, and no <param>.  See
> >attached.
> >
> >Results:  I tried 3 viewers (don't have access to Ulrich's right
now).
> >
> >PTC's very old Beta 6 passed.  The other two did not.
> >
> >Don, Forrest (, Ulrich) -- could you look into it please?  This is a
> >most basic test of referencing a CGM into an HTML document.  It
really
> >should work, regardless of whether the viewer is capable of more
> >advanced configurations (like loading via DOM), and regardless of
> >whether IE sometimes has issues with <param> child elements.
> >
> >Regards,
> >-Lofton.
> >
> >---------------------------------------------------------------------
> >To unsubscribe from this mail list, you must leave the OASIS TC that
> >generates this mail.  Follow this link to all your TCs in OASIS at:
>
>https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
>
>
>---------------------------------------------------------------------
>To unsubscribe from this mail list, you must leave the OASIS TC that
>generates this mail.  Follow this link to all your TCs in OASIS at:
>https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php


---------------------------------------------------------------------
To unsubscribe from this mail list, you must leave the OASIS TC that
generates this mail.  Follow this link to all your TCs in OASIS at:
https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php 



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