[Mono-list] ECMA compliance (and OCXT)

[Serge]

Joel,

Thanks for your detailed response.

> OCXT produces compilable code. See the release notes at

Unfortunatelly, I still can't test OCXT myself, but I applied my own
codegenerator to the library file found at
http://cedar.intel.com/media/xml/AllTypes.xml
So far I noticed only one real error in the library file:
Both signatures for System.Type (IL and C#) claims that it extends Object,
whereas it's base class is MemberInfo, this makes overriding DeclaringType &
ReflectedType properties illegal (later in member's signatures).
I downloaded OCL code (ver. 0.2.0), Type extends MemberInfo there (so I
guess it's generated from the older file?).

BTW, I noticed many new methods in the most recent XML library description,
such as Volatile* methods of Thread class.

> RTF should be easy to incorporate into the existing OCXT and I also would

Just an idea. Maybe it's worth considering rendering documentation in
xsl:fo? Theoretically, this would make it possible to convert it into
different "printable" formats.

Thanks,
Sergey



----- Original Message -----
From: "Marcey, Joel I" <joel.i.marcey@intel.com>
To: "'Serge'" <serge@wildwestsoftware.com>; "Mono-List"
<mono-list@ximian.com>
Sent: Wednesday, November 28, 2001 3:00 AM
Subject: RE: [Mono-list] ECMA compliance (and OCXT)


> 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.
>