Re: XmlHttpRequest IDL non normative

2006-08-10 Thread Anne van Kesteren


On Wed, 26 Jul 2006 08:52:46 +0200, José Manuel Cantera Fonseca  
[EMAIL PROTECTED] wrote:
It really sounds strange to me. To specify something in IDL that is  
not OMG-IDL-conformant but you are going to use the bindings of  
OMG-IDL.


I'm not sure what you mean by us[ing] the bindings of OMG-IDL, but I  
don't think we are. The IDL in the draft is there because it's  
intuitive to people who are used to the DOM specifications and the  
such. We're not trying to conform to OMG IDL simply because it's not  
powerful enough to capture what we need to express.


Bindings is the word that is used in the document :-)


Actually. Language bindings is what's used in the document.


I think that a document that tries to standardize something and itself  
doesn't conform or adhere other standards is simply nonsense.


The IDL is simply non normative and illustrates the API. The actual  
language bindings (not yet included in the document) will define the exact  
mapping to ECMAScript and perhaps other languages.


I don't see the problem.


If you are not going to use the sintax and semantics of OMG-IDL it  
could be better not specifying the object in IDL. You could do it  
directly in EcmaScript.


I'm not sure Ecmascript would be a good option here, but I don't have a  
strong opinion. The best option would be to document a Web API IDL  
but that's quite a lot of work.


Why ECMAScript is not a good option? All the DOM developers and Web  
Developers know the language and in fact the APIs you are trying to  
standardize are yet defined in browsers and developers are used to use  
them from EcmaScript.


As far as I know ECMAScript has no notion of IDLs... Anyway, I agree with  
Robin, we need a Web API IDL document. Unfortunately, I have no clue as  
how to write such a thing.



--
Anne van Kesteren
http://annevankesteren.nl/
http://www.opera.com/




Re: XmlHttpRequest IDL non normative

2006-07-26 Thread José Manuel Cantera Fonseca


Robin Berjon escribió:

On Jul 24, 2006, at 16:24, José Manuel Cantera Fonseca wrote:
It really sounds strange to me. To specify something in IDL that is 
not OMG-IDL-conformant but you are going to use the bindings of OMG-IDL.


I'm not sure what you mean by us[ing] the bindings of OMG-IDL, but I 
don't think we are. The IDL in the draft is there because it's 
intuitive to people who are used to the DOM specifications and the 
such. We're not trying to conform to OMG IDL simply because it's not 
powerful enough to capture what we need to express.


Bindings is the word that is used in the document :-) . I think is a 
mistake, they are referring to language mappings, that is, the rules 
that govern how each element in IDL is mapped to an element in a 
concrete programming language. If you don't conform to something it's 
better not to use it. It makes nonsense. What a dialect of IDL are you 
inventing? I think that a document that tries to standardize something 
and itself doesn't conform or adhere other standards is simply nonsense.


If you are not going to use the sintax and semantics of OMG-IDL it 
could be better not specifying the object in IDL. You could do it 
directly in EcmaScript.


I'm not sure Ecmascript would be a good option here, but I don't have 
a strong opinion. The best option would be to document a Web API IDL 
but that's quite a lot of work.
Why ECMAScript is not a good option? All the DOM developers and Web 
Developers know the language and in fact the APIs you are trying to 
standardize are yet defined in browsers and developers are used to use 
them from EcmaScript.


--Robin Berjon
   Senior Research Scientist
   Expway, http://expway.com/









Re: XmlHttpRequest IDL non normative

2006-07-25 Thread Robin Berjon


On Jul 24, 2006, at 16:24, José Manuel Cantera Fonseca wrote:
It really sounds strange to me. To specify something in IDL that is  
not OMG-IDL-conformant but you are going to use the bindings of OMG- 
IDL.


I'm not sure what you mean by us[ing] the bindings of OMG-IDL, but  
I don't think we are. The IDL in the draft is there because it's  
intuitive to people who are used to the DOM specifications and the  
such. We're not trying to conform to OMG IDL simply because it's not  
powerful enough to capture what we need to express.


If you are not going to use the sintax and semantics of OMG-IDL it  
could be better not specifying the object in IDL. You could do it  
directly in EcmaScript.


I'm not sure Ecmascript would be a good option here, but I don't have  
a strong opinion. The best option would be to document a Web API  
IDL but that's quite a lot of work.


--
Robin Berjon
   Senior Research Scientist
   Expway, http://expway.com/





XmlHttpRequest IDL non normative

2006-07-24 Thread José Manuel Cantera Fonseca





Dear all,

I have seen the the following statement: in the working draft [1] that
specifies the XMLHttpRequestObject 

"A more complete description of what can be done with XMLHttpRequest
can be found in the IDL
below and its associated details. The IDL is non-normative and
does not intend to conform to [OMGIDL]. Only the language bindings are
normative."

It really sounds strange to me. To specify something in IDL that is not
OMG-IDL-conformant but you are going to use the bindings of OMG-IDL.
Strange. 

If you are not going to use the sintax and semantics of OMG-IDL it
could be better not specifying the object in IDL. You could do it
directly in EcmaScript. IDL is accurate when you have to deal with
multiple programming languages, but this is not the case. 

Best Regards

Jose Manuel Cantera
Senior Technologist
Telefonica I+D

[1] http://www.w3.org/TR/XMLHttpRequest/





Re: XmlHttpRequest IDL non normative

2006-07-24 Thread Mark Baker


+1

On 7/24/06, José Manuel Cantera Fonseca [EMAIL PROTECTED] wrote:

 If you are not going to use the sintax and semantics of OMG-IDL it could be
better not specifying the object in IDL. You could do it directly in
EcmaScript. IDL is accurate when you have to deal with multiple programming
languages, but this is not the case.