Re: [discuss] Some explanations on my "macro standard" nagging
M. Fioretti wrote: > On Wed, Jun 08, 2005 13:54:43 PM -0400, Daniel Carrera > ([EMAIL PROTECTED]) wrote: > >> Top posting. >> >> I think that adding Javascript-like functionality would be a worthy >> goal. In fact... we should Javascript itself the first macro language >> and make it do everything Javascript currently does on web pages. > [...] > >> In any event, back to your note. Having Javascript work with OD files >> would be the way to go if OD were to work with the web of the future. >> > > Me, I've nothing serious against JavaScript, except, maybe, the fact > that if one goes Python, Perl or similar, he may reuse some of that > knowledge in other areas of computing. Please let me repeat that the runtime language should be irrelevant, binding your application to a particular scripting language is dumb and not future-proof. The concept of language bindings as offered by UNO, COM or .NET is very powerful and allows to switch to other languages in the future. Of course for a standard you must select a mandatory language that everybody needs to support but which language this might be is completely irrelevant in the beginning. The language binding concept allows you to add further mandatory languages later on if it seems to be appropriate. It's the API that counts and that must be standardized. If this is done, you can think about the preferred language and of course you should choose one that is standardized by itself (that saves time ;-)). JavaScript would be a good choice because an ECMA Standard exists. Basic obviously would be a bad choice, I don't know if Python can be seen as standardized. Best regards, Mathias -- Mathias Bauer - OpenOffice.org Application Framework Project Lead Please reply to the list only, [EMAIL PROTECTED] is a spam sink. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [discuss] Some explanations on my "macro standard" nagging
Le mercredi 08 juin 2005 à 14:38 -0400, Daniel Carrera a écrit : > M. Fioretti wrote: > > > Please help me to understand it better: I read online that "XForms is > > a platform independent markup language for data capture and > > validation". Not necessarily data processing. > > > > Do you mean that one should "only write these "macros" in Xforms > > markup language" or that one should write them in $LANGUAGE but only > > accessing/reading/writing/processing XForms elements? > > All of this from within OO.o? > > Yeah... I don't think xforms can do everything Javascript can. I realize > that xforms are supposed to make JS unnecessary for *forms*. But there > is more to macros than forms. For example, I could make a tic tac toe > game with Javascript, and I doubt I could with xforms. However who'd need a standard way to do tic tac toe ? If everyone uses macros for the same things, that means you can do XForm-like standardisation. People who want to do tic tac toe games won't complain about standards later - it's not the same use cases at all. Regards, -- Nicolas Mailhot
Re: [discuss] Some explanations on my "macro standard" nagging
M. Fioretti wrote: Please help me to understand it better: I read online that "XForms is a platform independent markup language for data capture and validation". Not necessarily data processing. Do you mean that one should "only write these "macros" in Xforms markup language" or that one should write them in $LANGUAGE but only accessing/reading/writing/processing XForms elements? All of this from within OO.o? Yeah... I don't think xforms can do everything Javascript can. I realize that xforms are supposed to make JS unnecessary for *forms*. But there is more to macros than forms. For example, I could make a tic tac toe game with Javascript, and I doubt I could with xforms. Cheers, Daniel. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [discuss] Some explanations on my "macro standard" nagging
On Wed, Jun 08, 2005 13:54:43 PM -0400, Daniel Carrera ([EMAIL PROTECTED]) wrote: > Top posting. > > I think that adding Javascript-like functionality would be a worthy > goal. In fact... we should Javascript itself the first macro language > and make it do everything Javascript currently does on web pages. [...] > In any event, back to your note. Having Javascript work with OD files > would be the way to go if OD were to work with the web of the future. > Me, I've nothing serious against JavaScript, except, maybe, the fact that if one goes Python, Perl or similar, he may reuse some of that knowledge in other areas of computing. However, I vaguely remember to have read somewhere in these threads arguing *against* it, so I'll wait for more knowledgeable comments. Thanks for pointing JavaScript out! Marco -- Marco Fiorettimfioretti, at the server mclink.it Fedora Core 3 for low memory http://www.rule-project.org/ Never let your sense of morals prevent you from doing what is right Salvor Hardin , "Foundation" - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [discuss] Some explanations on my "macro standard" nagging
On Wed, Jun 08, 2005 19:45:26 PM +0200, Nicolas Mailhot ([EMAIL PROTECTED]) wrote: > Le mercredi 08 juin 2005 à 19:14 +0200, M. Fioretti a écrit : > > >define what could be a limited, more realistic goal (the > >"javascript-like", in-document only macros), and list what one > >should do, what to read, which lists to join etc... to give a hand > > The "limited" stuff is what XForms is about : a clearly delimited set of > functionality, with a standard way of expressing it. > > Any proposal that's just let's use a langage (basic, python, javascript) > without defining compliance profiles is just opening up the doors for > incompatible implementations (because the core will be the same but the > overlaps limited) Please help me to understand it better: I read online that "XForms is a platform independent markup language for data capture and validation". Not necessarily data processing. Do you mean that one should "only write these "macros" in Xforms markup language" or that one should write them in $LANGUAGE but only accessing/reading/writing/processing XForms elements? All of this from within OO.o? TIA, Marco -- Marco Fiorettimfioretti, at the server mclink.it Fedora Core 3 for low memory http://www.rule-project.org/ ... Work like you don't need money, love like you've never been hurt, and dance like nobody is watching. Anonymous - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [discuss] Some explanations on my "macro standard" nagging
Top posting. I think that adding Javascript-like functionality would be a worthy goal. In fact... we should Javascript itself the first macro language and make it do everything Javascript currently does on web pages. Why? I'm glad you ask! Gary Edwards has this great idea of talking to W3C to grab OpenDocument as the evolutionary step after XHTML. It's possible. OpenDocument brings together a lot of W3C standards, and OD itself is an OASIS standard and soon will be an ISO standard. Finally, W3C is in regular contact with the OASIS technical committee that oversees OpenDocument. So... the idea of OD becomming a W3C recommendation is not far out. Making it the replacement of XHTML is harder, but not impossible. In any event, back to your note. Having Javascript work with OD files would be the way to go if OD were to work with the web of the future. Cheers, Daniel. M. Fioretti wrote: Greetings, in the last two days I've been able to check this list only through webmail, that is in an almost unreadable interface. I have seen there have been a lot of posts about my "obsession" with doing portable OpenDocument macros in Python or whatever else. Due to the problems above I've been only able to read some parts of only a few messages. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[discuss] Some explanations on my "macro standard" nagging
Greetings,
in the last two days I've been able to check this list only through
webmail, that is in an almost unreadable interface. I have seen there
have been a lot of posts about my "obsession" with doing portable
OpenDocument macros in Python or whatever else. Due to the problems
above I've been only able to read some parts of only a few messages.
I will re-read them and answer when needed now, but what I read from
webmail makes me already think it's necessary to (re)-explain why I'm
making such a pest of myself, to put everything in context.
I am not a C/C++ programmer and have no time or skills to become one
in the foreseable future.
However, I am an advanced Linux user, pretty good with shell, Perl and
other kinds of scripting, and *very* interested in advancement of open
standards. So, yes, I do know just enough IT to be obnoxious, but I am
(I hope) aware of it most of the time, and do it in good faith.
I have realized that:
macros are not portable across OO.o KOffice and other future
OpenDocument processors
end users *will* expect them to be portable, since "they are into
the file whose format is standard, didn't you tell us so?"
this and similar things can become sensible PR problems for OO.o and
FOSS in general ("MS was right, this darn FOSS circus *is* so
fragmented and lacking a common strategy to be unusable...")
almost all developers I've asked about this had never realized the
last two points above. Some *have* expressed interest and said it is
a good idea which should be worked on in the future.
So,
I agree a macro scripting standard should not be part of OpenDocument
I agree that it will never be able to replicate everything in the
current OO.o API, and agree that it would be unnecessary, to say the
least
I am sure that if this ever becomes a standard as I hope, it should be
ratified (under a truly open IP policy) from OASIS or similar
organizations, otherwise it won't be taken seriously
I am *not* asking you or anybody else to do it for me yesterday
but I want to write an article that:
explains the problem, so IT-challenged end users (and buyers)
will be aware of it, and don't plague oo-users and
similar lists with "macros aren't portable" complaints
two years from now (*)
define what is unnecessary/unrealistic to ask and why
define what could be a limited, more realistic goal (the
"javascript-like", in-document only macros), and list what one
should do, what to read, which lists to join etc... to give a hand
(consider that EU and other public organizations around *do* fund
from time to time far-fetched FOSS-related projects, so if all this
makes them fund some third party to do it, everybody is happy:
stranger things have happened...)
So this is the context in which my questions should be read: there is
a practical reason and, I hope, something useful to the whole
community in helping me to sort this out.
Back to the original thread now.
TIA,
Marco
(*) Who am I kidding? They *will* come in droves to bother you, but
you will be able to just tell them "Shut up and just read Marco's
article to know why not!". Am I helpful or what? :-)
--
Marco Fiorettimfioretti, at the server mclink.it
Fedora Core 3 for low memory http://www.rule-project.org/
"A good day is for me much food, much sex, much children."
Kirstie Alley
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
