RE: Clarification on <OBJECT> element details.

Hi Mukul,

thanks for your comments.

You are correct in assumption about the definition of <object>: since
objects are platform-specific, the platform itself needs to define
exactly what values should be assigned to the object parameters.

1. codetype/type could be a Java applicaiton for example.

2. codebase indicates the general base URI used to resolve relative URIs
in classid, data and archive. Classid is a URI for the object's
implementation -- if relative, it is resolved against the codebase.

3. the assumption is that there is one master class associated with the
object --- it in turn can load other classes following standard
procedures in java, c++, etc.

I hope this helps. If you think there is a specific problem with the
specification which prevents its proper implementation and use, then
please let me know. If so, please suggest precise wording for any
proposed alternatives. 


[leader, W3C VBWG VoiceXML 2.0 dialog team]

-----Original Message-----
From: Mukul Jain []
Sent: Tuesday, July 02, 2002 21:31
To: Www-Voice@W3. Org
Subject: Clarification on <OBJECT> element details.


I feel the <object> element definition is pretty loose and subject to
readers interpretation. It could be intentional as <object> elements are
always going to be platform specific anyway.

Seeking clarifications for:

1.. What could be the possible values for "codetype" and "type"
say for example object is implemented using C++ or JAVA?

2. Definition of "codebase" and "classid" is also not very clear as one
them seem to be standard URI convention whereas other one is
platform-dependent and then it is said that "codebase" is used to
relative path. It would be little counter intuitive to combine a
platform-dependent URI convention with one of the standard URI
for the purpose of resolving relative paths.

3. Does the current form of spec takes care of situation where object
implementation spreads in multiple classes? If, yes, how do we define
classids for other classes.

Mukul Jain

Received on Tuesday, 23 July 2002 06:18:32 UTC