[Mono-list] ECMA compliance (and OCXT)

[Marcey, Joel I]

Hey Serge, all,

Comments below.

>>It's very similar to OCXT except for that the main XSLT script is portable
>>:)
>>OCXT scripts are generally not portable, because they use msxsl
extensions.
>>I think it's rather unfortunate choice to rely on Office/Word for such a
>>tool.

The original intent of the tool that has now become known as OCXT was to be
able to generate, from the normative XML definition, the Microsoft Word
documentation that is being used as an informative annex to the ECMA CLI
specification. Thus, reliance on Microsoft Word and associated extensions
seemed warranted. Intel actually decided to use OCXT as a code generation
tool after the fact and in order to produce auto-generated code as quickly
as possible, it made sense to modify the already existing tool. Nowadays the
code generation is a lot more popular than the documentation generation.
What I would love to see is OCXT be the tool of choice to produce code as
well as documentation. And I am not against having the tool be modified in
order to be more portable and not have to rely on Microsoft Word for the
code generation...in fact that was the next item I was going to look at. My
suggestion is that we consolidate the work of auto generation into OCXT so
there can be one place to produce code as well as documentation. In other
words, let's establish some developers on the OCXT site and start
changing/adding to the tool. What do you think?

>>The older XML library-definitions have contained some errors that made it
>>very hard to generate compilable code. I hope this is fixed in the newer
>>file. 
>>The newer format
>>contains more information, but older contains more classes. Some stuff in
>>the older file is still relevant, mostly values for some enums - it
appears

The most recent XML file is what is being submitted to the ECMA General
Assembly for standardization, so its contents supercedes any of the older
XML files with respect to ECMA standards compliance. Now you are right that
the older XML file may contain other suitable information for the Mono
project, but that is beyond the scope of ECMA compliance.

>>If OCXT produces fully compilable code (or newer XML file is fixed) 

OCXT produces compilable code. See the release notes at
http://sourceforge.net/projects/ocl to learn more.

>>Also, I'd personally would love to see documentation rendered in PDF or
RTF
>>instead of DOC.

RTF should be easy to incorporate into the existing OCXT and I also would
like to see OCXT be able to produce PDF. Another reason to get some
development on OCXT.

Thanks,
- Joel Marcey

** The views and statements expressed here do not necessarily reflect those
of
Intel Corporation, its subsidiaries or its employees.

----- Original Message -----
From: "Nick Drochak" <ndrochak@gol.com>
To: "Mono-List" <mono-list@ximian.com>
Cc: "Nick D Drochak" <ndrochak@gol.com>
Sent: Thursday, November 22, 2001 8:04 AM
Subject: RE: [Mono-list] ECMA compliance


> | Interest?  Suggestions?  Disdain? ;-)
> |
>
> I am interested in such a thing.  It would be a useful "unit test" to make
> sure that no one accidentally changes a class in such a way to break it's
> interface.
>
> Perhaps we can extend Sergey's verifier?  At the very least I'm sure
there's
> some good code in there we can factor out and use.
>
>
> Nick D.
>
>
> _______________________________________________
> Mono-list maillist  -  Mono-list@ximian.com
> http://lists.ximian.com/mailman/listinfo/mono-list
>




_______________________________________________
Mono-list maillist  -  Mono-list@ximian.com
http://lists.ximian.com/mailman/listinfo/mono-list