[EROS-Arch] capidl alive again
Jonathan S. Shapiro
shap@eros-os.org
Mon, 17 Sep 2001 15:25:35 -0400
This is a multi-part message in MIME format.
------=_NextPart_000_059A_01C13F8C.FF698000
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Just so people know, the capidl project is alive again. We ran into some =
things needed for EROS that I just couldn't hack up with XSLT.
The first thing that Mark Miller and I need to converge on is the =
grammar -- we have some pending issues there.The current, VERY stale, =
grammar can be found at:
http://www.eros-os.org/capidl-src/capidl-grammar.y
Don't confuse this with gram.y, which is the working grammar. I'm in the =
process (i.e. today) of stripping the working grammar down to do an =
update on the base grammar. Eventually, the official capidl grammar will =
move to the capidl site, but for the moment this is probably the easiest =
location to track it. By the time it moves we'll hopefully have PCMS to =
track projects with, and the whole idea of "server of origin" will be =
moot.
If you wish to track capidl, subscribe to the capidl list via =
http://www.eros-os.org/mailman/listinfo -- both discussion AND cvs =
messages will appear here, which is different from our other lists. I =
can separate these if people find this awkward, but I expect this to be =
fast paced and then done, because I don't have time to do it any other =
way.
The project itself can be checked out from the cvs.eros-os.org site via =
anoncvs. Follow the directions for eros anonymous checkout, but check =
out the 'capidl' project instead.
The current plan is to do a first implementation of CapIDL in C, with a =
Java-hosted version to be built at an unspecified later time. In order =
to facilitate interim use of the C version from within Java/E, we =
currently plan to provide a back end that outputs the intermediate parse =
tree directly as XML. Still TBD whether this will be MinXML, because =
attributes are actually really useful things, and real XML parsing isn't =
that hard; the problem is the content model. At a minimum, MarkM and I =
have agreed to use the sensible (XPath) content model rather than the =
official one.
So the steps are:
1. Nail down the grammar.
2. Specify the semantics, where needed.
3. Nail down the canonical representation.
4. Implement back-ends that generate C, XML (of parse tree), XML (for =
docs), C++, Java.
I'm including Java backend specifically because the runtime model is =
different, but I would much prefer that somebody else build that by =
re-reading the XML parse tree. Any volunteers?
Because the IDL specification must include things like order codes, we =
won't get the degree of separation that CorbaIDL does. Also, unlike =
Corba, CapIDL is used first and foremost as a *local* IDL, and it is now =
well established that serialization and representation is a substantial =
part of the local RPC overhead. With that given as motivation, I think =
it also safe to say that implementations are free to optimize the local =
case within a given runtime as they wish, provided that doing so does =
not interfere with the ability to generate the canonical serialization =
when needed or violate the underlying semantics of the wire =
representation (e.g. by getting caught sharing state across protection =
domains when they shouldn't).
As to using XML output for the documentation...
There are two main reasons to use XML for documentation in CapIDL.
1. Many projects will want their output to serve other needs in the =
documentation chain, possibly including further analysis. Because of =
this, they may want the input documentation to conform to some external =
DTD. To this end, MarkM and I have resolved that (a) CapIDL document =
comments must be well-formed XML trees, and that (b) the user can =
specify the DTD and root element for each documentation comment type. To =
facilitate use of HTML docs in the style currently used for JavaDOC, =
I'll at some point generate an XHTML fragment DTD that is augmented with =
tags for variables, arguments, etc. in the style of the javadoc @foo{} =
tags (which were a terrible idea given the already existing <span> =
mechanism in HTML.
2. Unlike HTML output, which is very presentation oriented, XML output =
need not be information losing. It is very easy to build an XSLT script =
that can be used in either Java or command line (xsltproc) to strip this =
to generate strict HTML. It is not very easy to reconstruct the =
information once it has been stripped out.
It is a consequence of (1) that there is no canonical HTML input, and =
therefore that there can be no canonical HTML output transformation. For =
ease of use, the C version can at some point simply integrate libxml and =
libxslt for this purpose. In the Java version, we can similarly =
integrate, say, xalan and xerces libraries for this purpose.
There are now reasonably good XSLT processors for both Java and C. We =
will provide both a canonical IDLdoc DTD and a canonical XSLT =
transformer that generates HTML output provided that the IDLdoc DTD is =
used.
------=_NextPart_000_059A_01C13F8C.FF698000
Content-Type: text/html;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3Diso-8859-1">
<META content=3D"MSHTML 5.50.4807.2300" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV><FONT face=3DArial size=3D2>Just so people know, the capidl project =
is alive=20
again. We ran into some things needed for EROS that I just couldn't hack =
up with=20
XSLT.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT> </DIV>
<DIV><FONT face=3DArial size=3D2>The first thing that Mark Miller and I =
need to=20
converge on is the grammar -- we have some pending issues there.The =
current,=20
VERY stale, grammar can be found at:</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT> </DIV>
<DIV><FONT face=3DArial size=3D2><A=20
href=3D"http://www.eros-os.org/eros-src/base/cross/bin/capidl/capidl-gram=
mar.y"> =20
</A><A=20
href=3D"http://www.eros-os.org/capidl-src/capidl-grammar.y">http://www.er=
os-os.org/capidl-src/capidl-grammar.y</A></FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT> </DIV>
<DIV><FONT face=3DArial size=3D2>Don't confuse this with gram.y, which =
is the=20
working grammar. I'm in the process (i.e. today) of stripping the =
working=20
grammar down to do an update on the base grammar. Eventually, the =
official=20
capidl grammar will move to the capidl site, but for the moment this is =
probably=20
the easiest location to track it. By the time it moves we'll hopefully =
have PCMS=20
to track projects with, and the whole idea of "server of origin" will be =
moot.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT> </DIV>
<DIV><FONT face=3DArial size=3D2>If you wish to track capidl, subscribe =
to the=20
capidl list via <A=20
href=3D"http://www.eros-os.org/mailman/listinfo">http://www.eros-os.org/m=
ailman/listinfo</A> --=20
both discussion AND cvs messages will appear here, which is different =
from our=20
other lists. I can separate these if people find this awkward, but I =
expect this=20
to be fast paced and then done, because I don't have time to do it any =
other=20
way.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT> </DIV>
<DIV><FONT face=3DArial size=3D2>The project itself can be checked out =
from the=20
cvs.eros-os.org site via anoncvs. Follow the directions for eros =
anonymous=20
checkout, but check out the 'capidl' project instead.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT> </DIV>
<DIV><FONT face=3DArial size=3D2>The current plan is to do a first =
implementation of=20
CapIDL in C, with a Java-hosted version to be built at an unspecified =
later=20
time. In order to facilitate interim use of the C version from within =
Java/E, we=20
currently plan to provide a back end that outputs the intermediate parse =
tree=20
directly as XML. Still TBD whether this will be MinXML, because =
attributes are=20
actually really useful things, and real XML parsing isn't that hard; the =
problem=20
is the content model. At a minimum, MarkM and I have agreed to use the =
sensible=20
(XPath) content model rather than the official one.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT> </DIV>
<DIV><FONT face=3DArial size=3D2>So the steps are:</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT> </DIV>
<DIV><FONT face=3DArial size=3D2>1. Nail down the grammar.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>2. Specify the semantics, where=20
needed.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>3. Nail down the canonical=20
representation.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>4. Implement back-ends that generate C, =
XML (of=20
parse tree), XML (for docs), C++, Java.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT> </DIV>
<DIV><FONT face=3DArial size=3D2>I'm including Java backend specifically =
because the=20
runtime model is different, but I would much prefer that somebody else =
build=20
that by re-reading the XML parse tree. Any volunteers?</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT> </DIV>
<DIV><FONT face=3DArial size=3D2>Because the IDL specification must =
include things=20
like order codes, we won't get the degree of separation that CorbaIDL =
does.=20
Also, unlike Corba, CapIDL is used first and foremost as a *local* IDL, =
and it=20
is now well established that serialization and representation is a =
substantial=20
part of the local RPC overhead. With that given as motivation, I think =
it also=20
safe to say that implementations are free to optimize the local case =
within a=20
given runtime as they wish, provided that doing so does not interfere =
with the=20
ability to generate the canonical serialization when needed or violate =
the=20
underlying semantics of the wire representation (e.g. by getting caught =
sharing=20
state across protection domains when they shouldn't).</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT> </DIV>
<DIV><FONT face=3DArial size=3D2>As to using XML output for the=20
documentation...</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT> </DIV>
<DIV><FONT face=3DArial size=3D2>There are two main reasons to use XML =
for=20
documentation in CapIDL.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT> </DIV>
<DIV><FONT face=3DArial size=3D2>1. Many projects will want their output =
to serve=20
other needs in the documentation chain, possibly including further =
analysis.=20
Because of this, they may want the input documentation to conform to =
some=20
external DTD. To this end, MarkM and I have resolved that (a) CapIDL =
document=20
comments must be well-formed XML trees, and that (b) the user can =
specify the=20
DTD and root element for each documentation comment type. To facilitate =
use of=20
HTML docs in the style currently used for JavaDOC, I'll at =
some point=20
generate an XHTML fragment DTD that is augmented with tags for =
variables,=20
arguments, etc. in the style of the javadoc @foo{} tags (which were a =
terrible=20
idea given the already existing <span> mechanism in =
HTML.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT> </DIV>
<DIV><FONT face=3DArial size=3D2>2. Unlike HTML output, which is very =
presentation=20
oriented, XML output need not be information losing. It is very easy to =
build an=20
XSLT script that can be used in either Java or command line (xsltproc) =
to strip=20
this to generate strict HTML. It is not very easy to reconstruct the =
information=20
once it has been stripped out.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT> </DIV>
<DIV><FONT face=3DArial size=3D2>It is a consequence of (1) that there =
is no=20
canonical HTML input, and therefore that there can be no canonical HTML =
output=20
transformation. For ease of use, the C version can at some point simply=20
integrate libxml and libxslt for this purpose. In the Java version, we =
can=20
similarly integrate, say, xalan and xerces libraries for this=20
purpose.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT> </DIV>
<DIV><FONT face=3DArial size=3D2>There are now reasonably good XSLT =
processors for=20
both Java and C. We will provide both a canonical IDLdoc DTD and a =
canonical=20
XSLT transformer that generates HTML output provided that the IDLdoc DTD =
is=20
used.</FONT></DIV></BODY></HTML>
------=_NextPart_000_059A_01C13F8C.FF698000--