[prev in list] [next in list] [prev in thread] [next in thread]
List: eros-arch
Subject: [EROS-Arch] capidl alive again
From: "Jonathan S. Shapiro" <shap () eros-os ! org>
Date: 2001-09-17 19:25:35
[Download RAW message or body]
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.
[Attachment #3 (text/html)]
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=Content-Type content="text/html; charset=iso-8859-1">
<META content="MSHTML 5.50.4807.2300" name=GENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=#ffffff>
<DIV><FONT face=Arial size=2>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.</FONT></DIV>
<DIV><FONT face=Arial size=2></FONT> </DIV>
<DIV><FONT face=Arial size=2>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:</FONT></DIV>
<DIV><FONT face=Arial size=2></FONT> </DIV>
<DIV><FONT face=Arial size=2><A
href="http://www.eros-os.org/eros-src/base/cross/bin/capidl/capidl-grammar.y"> \
</A><A
href="http://www.eros-os.org/capidl-src/capidl-grammar.y">http://www.eros-os.org/capidl-src/capidl-grammar.y</A></FONT></DIV>
<DIV><FONT face=Arial size=2></FONT> </DIV>
<DIV><FONT face=Arial size=2>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.</FONT></DIV>
<DIV><FONT face=Arial size=2></FONT> </DIV>
<DIV><FONT face=Arial size=2>If you wish to track capidl, subscribe to the
capidl list via <A
href="http://www.eros-os.org/mailman/listinfo">http://www.eros-os.org/mailman/listinfo</A> -- \
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.</FONT></DIV>
<DIV><FONT face=Arial size=2></FONT> </DIV>
<DIV><FONT face=Arial size=2>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.</FONT></DIV>
<DIV><FONT face=Arial size=2></FONT> </DIV>
<DIV><FONT face=Arial size=2>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.</FONT></DIV>
<DIV><FONT face=Arial size=2></FONT> </DIV>
<DIV><FONT face=Arial size=2>So the steps are:</FONT></DIV>
<DIV><FONT face=Arial size=2></FONT> </DIV>
<DIV><FONT face=Arial size=2>1. Nail down the grammar.</FONT></DIV>
<DIV><FONT face=Arial size=2>2. Specify the semantics, where
needed.</FONT></DIV>
<DIV><FONT face=Arial size=2>3. Nail down the canonical
representation.</FONT></DIV>
<DIV><FONT face=Arial size=2>4. Implement back-ends that generate C, XML (of
parse tree), XML (for docs), C++, Java.</FONT></DIV>
<DIV><FONT face=Arial size=2></FONT> </DIV>
<DIV><FONT face=Arial size=2>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?</FONT></DIV>
<DIV><FONT face=Arial size=2></FONT> </DIV>
<DIV><FONT face=Arial size=2>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).</FONT></DIV>
<DIV><FONT face=Arial size=2></FONT> </DIV>
<DIV><FONT face=Arial size=2>As to using XML output for the
documentation...</FONT></DIV>
<DIV><FONT face=Arial size=2></FONT> </DIV>
<DIV><FONT face=Arial size=2>There are two main reasons to use XML for
documentation in CapIDL.</FONT></DIV>
<DIV><FONT face=Arial size=2></FONT> </DIV>
<DIV><FONT face=Arial size=2>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.</FONT></DIV>
<DIV><FONT face=Arial size=2></FONT> </DIV>
<DIV><FONT face=Arial size=2>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.</FONT></DIV>
<DIV><FONT face=Arial size=2></FONT> </DIV>
<DIV><FONT face=Arial size=2>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.</FONT></DIV>
<DIV><FONT face=Arial size=2></FONT> </DIV>
<DIV><FONT face=Arial size=2>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.</FONT></DIV></BODY></HTML>
_______________________________________________
eros-arch mailing list
eros-arch@mail.eros-os.org
http://www.eros-os.org/mailman/listinfo/eros-arch
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic