From shap@eros-os.org Mon Sep 17 14:25:58 2001 Received: from mail.eros-os.org (IDENT:root@EROS.CIS.UPENN.EDU [158.130.6.119]) by eros.cs.jhu.edu (8.11.0/8.11.0) with ESMTP id f8HIPwv01311 for ; Mon, 17 Sep 2001 14:25:58 -0400 Received: from eros.cs.jhu.edu (IDENT:root@eros.cs.jhu.edu [128.220.223.245]) by mail.eros-os.org (8.9.3/8.9.3) with ESMTP id OAA00998 for ; Mon, 17 Sep 2001 14:17:55 -0400 Received: from vmware (mikado.cs.jhu.edu [128.220.223.247]) (authenticated (0 bits)) by eros.cs.jhu.edu (8.11.0/8.11.0) with ESMTP id f8HIPuv01306 for ; Mon, 17 Sep 2001 14:25:56 -0400 Message-ID: <058901c13fa6$4a166ff0$021010ac@vmware> From: "Jonathan S. Shapiro" To: Date: Mon, 17 Sep 2001 14:26:38 -0400 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0586_01C13F84.C2DD23B0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4807.1700 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 Subject: [capidl] list kickstart Sender: capidl-admin@mail.eros-os.org Errors-To: capidl-admin@mail.eros-os.org X-BeenThere: capidl@mail.eros-os.org X-Mailman-Version: 2.0beta5 Precedence: bulk List-Id: This is a multi-part message in MIME format. ------=_NextPart_000_0586_01C13F84.C2DD23B0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable This is a welcome message purely to populate the archive. ------=_NextPart_000_0586_01C13F84.C2DD23B0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

This is a welcome message purely to = populate the=20 archive.

------=_NextPart_000_0586_01C13F84.C2DD23B0-- From shap@eros.cs.jhu.edu Mon Sep 17 15:12:03 2001 Received: from mail.eros-os.org (IDENT:root@EROS.CIS.UPENN.EDU [158.130.6.119]) by eros.cs.jhu.edu (8.11.0/8.11.0) with ESMTP id f8HJC3v02104 for ; Mon, 17 Sep 2001 15:12:03 -0400 Received: from eros.cs.jhu.edu (IDENT:root@eros.cs.jhu.edu [128.220.223.245]) by mail.eros-os.org (8.9.3/8.9.3) with ESMTP id PAA01175 for ; Mon, 17 Sep 2001 15:04:00 -0400 From: shap@eros.cs.jhu.edu Received: (from shap@localhost) by eros.cs.jhu.edu (8.11.0/8.11.0) id f8HJC3i02099 for capidl@eros-os.org; Mon, 17 Sep 2001 15:12:03 -0400 Date: Mon, 17 Sep 2001 15:12:03 -0400 Message-Id: <200109171912.f8HJC3i02099@eros.cs.jhu.edu> To: capidl@eros-os.org Subject: [capidl] cvs commit: capidl makerules.mk makevars.mk Makefile SymTab.cxx gram.y lex.l Sender: capidl-admin@mail.eros-os.org Errors-To: capidl-admin@mail.eros-os.org X-BeenThere: capidl@mail.eros-os.org X-Mailman-Version: 2.0beta5 Precedence: bulk List-Id: shap 01/09/17 15:12:03 Modified: . Makefile SymTab.cxx gram.y lex.l Added: . makerules.mk makevars.mk Log: Cleaned up checkin for in-progress UNIX capidl implementation Revision Changes Path 1.2 +7 -8 capidl/Makefile Index: Makefile =================================================================== RCS file: /cvs/capidl/Makefile,v retrieving revision 1.1 retrieving revision 1.2 diff -u -r1.1 -r1.2 --- Makefile 2001/09/17 18:43:23 1.1 +++ Makefile 2001/09/17 19:12:02 1.2 @@ -19,11 +19,9 @@ # -# Utility to convert a linux a.out file to a domain image file. -default: package +default: all -EROS_SRC=../../../.. -include $(EROS_SRC)/build/lib/make/makevars.mk +include makevars.mk TARGETS=capidl @@ -32,13 +30,14 @@ #OPTIM=-O OPTIM=-g OBJECTS= gram.o lex.o SymTab.o -INC= -I$(EROS_ROOT)/cross/include $(XENV_INCLUDE) -LIBS= $(EROS_ROOT)/cross/lib/liberos.a $(EROS_ROOT)/cross/lib/libdisk.a -LIBS+= $(EROS_ROOT)/cross/lib/libzlib.a +OBJECTS += Intern.o App.o AppPath.o AppExit.o AppFile.o Diag.o +INC= -I. +LIBS= OTHER_LIBS= -lbfd -liberty -lgmp DIRS= +VPATH=.:applib -include $(EROS_SRC)/build/lib/make/makerules.mk +include makerules.mk all: $(TARGETS) 1.2 +2 -3 capidl/SymTab.cxx Index: SymTab.cxx =================================================================== RCS file: /cvs/capidl/SymTab.cxx,v retrieving revision 1.1 retrieving revision 1.2 diff -u -r1.1 -r1.2 --- SymTab.cxx 2001/09/17 18:43:23 1.1 +++ SymTab.cxx 2001/09/17 19:12:02 1.2 @@ -23,9 +23,8 @@ /* GNU multiple precision library: */ #include -#include -#include -#include +#include +#include #include "SymTab.hxx" Symbol *GlobalScope = 0; /* scope for global symbols */ 1.2 +3 -6 capidl/gram.y Index: gram.y =================================================================== RCS file: /cvs/capidl/gram.y,v retrieving revision 1.1 retrieving revision 1.2 diff -u -r1.1 -r1.2 --- gram.y 2001/09/17 18:43:23 1.1 +++ gram.y 2001/09/17 19:12:02 1.2 @@ -79,12 +79,9 @@ /* GNU multiple precision library: */ #include -#include -#include -#include -#include -#include - +#include +#include +#include #include "SymTab.hxx" #include "ParseType.hxx" 1.2 +2 -6 capidl/lex.l Index: lex.l =================================================================== RCS file: /cvs/capidl/lex.l,v retrieving revision 1.1 retrieving revision 1.2 diff -u -r1.1 -r1.2 --- lex.l 2001/09/17 18:43:23 1.1 +++ lex.l 2001/09/17 19:12:02 1.2 @@ -27,12 +27,8 @@ /* GNU multiple precision library: */ #include -#include -#include - -#include -#include -#include +#include +#include #include "SymTab.hxx" #include "ParseType.hxx" 1.1 capidl/makerules.mk Index: makerules.mk =================================================================== # # Copyright (C) 2001, Jonathan S. Shapiro. # # This file is part of the EROS Operating System. # # This program is free software; you can redistribute it and/or # modify it under the terms of the GNU General Public License # as published by the Free Software Foundation; either version 2, # or (at your option) any later version. # # This program is distributed in the hope that it will be useful, # but WITHOUT ANY WARRANTY; without even the implied warranty of # MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the # GNU General Public License for more details. # # You should have received a copy of the GNU General Public License # along with this program; if not, write to the Free Software # Foundation, 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA. # unexport DIRS unexport ETAGDIRS unexport GENERATED unexport CLEANLIST # The following variables depend on things set in the makefile: GCCFLAGS=$(CFLAGS) $(OPTIM) $(INC) $(DEF) GPLUSFLAGS=-fdefault-inline -fno-implicit-templates $(OPTIM) $(GPLUS_OPTIM) $(INC) $(DEF) ifndef CLEANDIRS CLEANDIRS=$(DIRS) endif SEDHACK=sed 's,'$*'\.o[ :]*,'$@' &,g' DEP_SEDHACK=sed 's,^[^:]*:[:]*,'$@' &,g' #DEP_SEDHACK=sed 's,'$*'\.o[ :]*,'$@' &,g' C_DEP=@$(GCC) $(GCCFLAGS) $(GCCWARN) -E -M $< | $(DEP_SEDHACK) > $@ CXX_DEP=@$(GPLUS) $(GPLUSFLAGS) $(GPLUSWARN) -E -M $< | $(DEP_SEDHACK) > $@ ASM_DEP=@$(GPLUS) $(GCCFLAGS) -E -M $< | $(DEP_SEDHACK) > $@ C_BUILD=$(GCC) $(GCCFLAGS) $(GCCWARN) -c $< CXX_BUILD=$(GPLUS) $(GPLUSFLAGS) $(GPLUSWARN) -c $< ASM_BUILD=$(GPLUS) $(GCCFLAGS) -c $< -o $@ # # OLD autodependency rules -- retained for the time being. # # use GPLUS to allow C++ style comments: #.S.m: # @$(GPLUS) $(GCCFLAGS) -E -M $< | $(SEDHACK) > $@ # #.s.m: # @echo "Please rewrite .s file as .S file" # #.c.m: # @$(GCC) $(GCCFLAGS) $(GCCWARN) -E -M $< | $(SEDHACK) > $@ # # #.cxx.m: # @$(GPLUS) $(GPLUSFLAGS) $(GPLUSWARN) -E -M $< | $(SEDHACK) > $@ .%.m: %.S @$(GPLUS) $(GCCFLAGS) -E -M $< | $(SEDHACK) > $@ .%.m: %.s @echo "Please rewrite .s file as .S file" .%.m: %.c @$(GCC) $(GCCFLAGS) -E -M $< | $(SEDHACK) > $@ .%.m: %.cxx @$(GPLUS) $(GPLUSFLAGS) $(GPLUSWARN) -E -M $< | $(SEDHACK) > $@ # # Object construction rules # .S.o: $(GPLUS) $(GCCFLAGS) -c $< -o $@ .c.o: $(GCC) $(GCCFLAGS) $(GCCWARN) -c $< .cxx.o: $(GPLUS) $(GPLUSFLAGS) $(GPLUSWARN) -c $< # Rules to process XML files to produce HTML: .xml.html: $(XSLT) -o $@ $(EROS_SRC)/doc/www/DTD/html-doc.xslt $< .%.xml.m: %.xml @echo "$(<:.xml=.html): $< $(EROS_SRC)/doc/www/DTD/html-doc.xslt" > $@ .ltx.dvi: latex $< latex $< .fig.gif: @if [ \! -x $(NETPBMDIR)/ppmtogif ]; then\ echo "ERROR: Please set the NETPBMDIR environment variable to identify"; \ echo " the location of the NetPBM directory."; \ exit 1;\ fi fig2dev -L ppm $< $*.ppm $(NETPBMDIR)/ppmtogif -t '#ffffff' $*.ppm > $@ -rm -f $*.ppm .PHONEY : depend nodepend recursive-depend all recursive-all install recursive-install clobber walk clean do-clean recursive-clean world world: $(MAKE) -C $(EROS_SRC) $(MAKERULES) install depend: recursive-depend DEPEND recursive-depend: ifneq "$(DIRS)" "" @for i in $(DIRS); do \ if [ -d "$$i" ]; then\ $(MAKE) -C $$i $(MAKERULES) depend; \ if [ $$? -ne 0 ]; then\ echo "*** RECURSIVE BUILD STOPS ***";\ exit 1;\ fi; \ fi; \ done endif all: recursive-all recursive-all: ifneq "$(DIRS)" "" @for i in $(DIRS); do \ if [ -d "$$i" ]; then\ $(MAKE) -C $$i $(MAKERULES) all; \ if [ $$? -ne 0 ]; then\ echo "*** RECURSIVE BUILD STOPS ***";\ exit 1;\ fi; \ fi; \ done endif install: recursive-install recursive-install: ifneq "$(DIRS)" "" @for i in $(DIRS); do \ if [ -d "$$i" ]; then\ $(MAKE) -C $$i $(MAKERULES) install; \ if [ $$? -ne 0 ]; then\ echo "*** RECURSIVE BUILD STOPS ***";\ exit 1;\ fi; \ fi; \ done endif # The following hack fixes up directory dependencies, and ALSO ensures # that the .m files will be rebuilt when appropriate: DEPEND: $(patsubst %.o,.%.m,$(OBJECTS)) $(patsubst %.xml,.%.xml.m,$(wildcard *.xml)) # @if [ -n "$(OBJECTS:.o=.m)" ]; then\ # cat *.m | sed "s, $(EROS_ROOT), \$$(EROS_ROOT),g" > DEPEND; \ # fi # @touch DEPEND # in case no .m files # @-rm -f *.m #local-depend: # @sed -e '/^### Output of make depend:/,$$d' Makefile > new.Makefile # @echo "### Output of make depend:" >> new.Makefile # @if [ -n "$(OBJECTS:.o=.m)" ]; then\ # cat *.m | sed "s, $(EROS_ROOT), \$$(EROS_ROOT),g" >> new.Makefile; \ # fi # @-rm -f *.m # @mv Makefile old.Makefile # @mv new.Makefile Makefile # @-rm -f old.Makefile all install: DEPEND nodepend: -find . -name '*.m' -exec rm {} \; -find . -name '.*.m' -exec rm {} \; -find . -name 'DEPEND' -exec rm {} \; ## The following piece of idiocy works around the fact that the ## autodependency files may refer to stuff that has been cleaned, ## and that this can therefore perversely cause the clean target to ## fail. clean: nodepend $(MAKE) $(MAKERULES) do-clean do-clean: recursive-clean -rm -f *.o *.m core *~ new.Makefile ".#"* -rm -f .*.m sysgen.map $(TARGETS) TAGS -rm -f *.dvi *.blg *.aux *.log *.toc $(CLEANLIST) recursive-clean: ifneq "$(CLEANDIRS)" "" @for i in $(CLEANDIRS); do \ if [ -d "$$i" ]; then\ $(MAKE) -C $$i $(MAKERULES) do-clean; \ if [ $$? -ne 0 ]; then\ echo "*** RECURSIVE BUILD STOPS ***";\ exit 1;\ fi; \ fi; \ done endif ## The following piece of idiocy works around the fact that the ## autodependency files may refer to stuff that has been clobbered, ## and that this can therefore perversely cause the clobber target to ## fail. clobber: @echo "Clobber target now obsolete: use clean instead" $(MAKE) $(MAKERULES) clean ifdef ETAGDIRS ETAGEXPAND=$(patsubst %,%/*.c,$(ETAGDIRS)) ETAGEXPAND+=$(patsubst %,%/*.cxx,$(ETAGDIRS)) ETAGEXPAND+=$(patsubst %,%/*.hxx,$(ETAGDIRS)) ETAGEXPAND+=$(patsubst %,%/*.h,$(ETAGDIRS)) ASM_ETAGEXPAND+=$(patsubst %,%/*.S,$(ETAGDIRS)) ETAGFILES=$(wildcard $(ETAGEXPAND)) ASM_ETAGFILES=$(wildcard $(ASM_ETAGEXPAND)) unexport ETAGEXPAND unexport ETAGFILES unexport ASM_ETAGEXPAND unexport ASM_ETAGFILES # --regex='/^struct[ \t]+$[A-Za-z0-9_]+$[ \t]*:[ \t]*public[ \t]+$[A-Za-z0-9_]+$/:public \1 \2/' \ # --regex='/^class[ \t]+$[A-Za-z0-9_]+$[ \t]*:[ \t]*public[ \t]+$[A-Za-z0-9_]+$/:public \1 \2/' \ tags: local-tags recursive-tags local-tags: etags \ --regex='/^struct[ \t]+$[A-Za-z0-9_]+$[ \t]*:[ \t]*public[ \t]+$[A-Za-z0-9_]+$/:public \1 \2/' \ --regex='/^class[ \t]+$[A-Za-z0-9_]+$[ \t]*:[ \t]*public[ \t]+$[A-Za-z0-9_]+$/:public \1 \2/' \ $(ETAGFILES) ifneq ($(ASM_ETAGFILES),) etags --append --lang=none \ --regex='/^$ENTRY\|GEXT$([A-Za-z0-9_\.]+)/' \ $(ASM_ETAGFILES) endif else tags: recursive-tags endif recursive-tags: ifneq "$(DIRS)" "" @for i in $(DIRS); do \ if [ -d "$$i" ]; then\ $(MAKE) -C $$i $(MAKERULES) tags; \ if [ $$? -ne 0 ]; then\ echo "*** RECURSIVE BUILD STOPS ***";\ exit 1;\ fi; \ fi; \ done endif generated: $(GENERATED) recursive-generated recursive-generated: ifneq "$(DIRS)" "" @for i in $(DIRS); do \ if [ -d "$$i" ]; then\ $(MAKE) -C $$i $(MAKERULES) generated; \ if [ $$? -ne 0 ]; then\ echo "*** RECURSIVE BUILD STOPS ***";\ exit 1;\ fi; \ fi; \ done endif # This is a debugging target.. walk: ifneq "$(DIRS)" "" @for i in $(DIRS); do \ $(MAKE) -C $$i $(MAKERULES) walk; \ if [ $$? -ne 0 ]; then\ echo "*** RECURSIVE BUILD STOPS ***";\ exit 1;\ fi; \ done endif 1.1 capidl/makevars.mk Index: makevars.mk =================================================================== # # Copyright (C) 2001, Jonathan S. Shapiro. # # This file is part of the EROS Operating System. # # This program is free software; you can redistribute it and/or # modify it under the terms of the GNU General Public License # as published by the Free Software Foundation; either version 2, # or (at your option) any later version. # # This program is distributed in the hope that it will be useful, # but WITHOUT ANY WARRANTY; without even the implied warranty of # MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the # GNU General Public License for more details. # # You should have received a copy of the GNU General Public License # along with this program; if not, write to the Free Software # Foundation, 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA. # # Cancel the old suffix list, because the order matters. We want assembly # source to be recognized in preference to ordinary source code, so the # .S, .s cases must come ahead of the rest. .SUFFIXES: .SUFFIXES: .S .s .cxx .c .y .l .o .dvi .ltx .gif .fig .xml .html # Some shells do not export this variable, and it is used in the package # generation rule below. ifeq "$(PWD)" "" PWD=$(shell pwd) endif # # First, set up variables for building native tools: # GAWK=gawk PYTHON=python #XML_LINT=$(EROS_XENV)/bin/xmllint #XSLT=$(EROS_XENV)/bin/xsltproc STRIP=strip OBJDUMP=objdump SIZE=size AR=ar LD=ld RANLIB=ranlib GCC=gcc GCCWARN=-Wall -Winline -Werror -Wno-format GPLUS=g++ GPLUSWARN=-Wall -Winline -Werror -Wno-format # search for ppmtogif in all the obvious places: ifndef NETPBMDIR ifneq "" "$(findstring /usr/bin/ppmtogif,$(wildcard /usr/bin/*))" NETPBMDIR=/usr/bin endif endif ifndef NETPBMDIR ifneq "" "$(findstring /usr/bin/X11/ppmtogif,$(wildcard /usr/bin/X11/*))" NETPBMDIR=/usr/bin/X11 endif endif ifndef NETPBMDIR ifneq "" "$(findstring /usr/local/netpbm/ppmtogif,$(wildcard /usr/local/netpbm/*))" NETPBMDIR=/usr/local/netpbm endif endif From markm@caplet.com Mon Sep 17 15:22:35 2001 Received: from mail.eros-os.org (IDENT:root@EROS.CIS.UPENN.EDU [158.130.6.119]) by eros.cs.jhu.edu (8.11.0/8.11.0) with ESMTP id f8HJMZv05454 for ; Mon, 17 Sep 2001 15:22:35 -0400 Received: from proxy4.ba.best.com (root@proxy4.ba.best.com [206.184.139.15]) by mail.eros-os.org (8.9.3/8.9.3) with ESMTP id PAA01199 for ; Mon, 17 Sep 2001 15:14:31 -0400 Received: from caplet.caplet.com (sdn-as-001njpennP324.dialsprint.net [158.252.58.134]) by proxy4.ba.best.com (8.9.3/8.9.2/best.out) with ESMTP id MAA17135; Mon, 17 Sep 2001 12:26:16 -0700 (PDT) Message-Id: <5.1.0.14.2.20010917122426.047e1710@shell9.ba.best.com> X-Sender: erights@shell9.ba.best.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Mon, 17 Sep 2001 12:25:37 -0700 To: shap@eros.cs.jhu.edu From: "Mark S. Miller" Subject: Re: [capidl] cvs commit: capidl makerules.mk makevars.mk Makefile SymTab.cxx gram.y lex.l Cc: capidl@eros-os.org In-Reply-To: <200109171912.f8HJC3i02099@eros.cs.jhu.edu> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: capidl-admin@mail.eros-os.org Errors-To: capidl-admin@mail.eros-os.org X-BeenThere: capidl@mail.eros-os.org X-Mailman-Version: 2.0beta5 Precedence: bulk List-Id: I think the cvs messages should go to a separate list, such as capidl-cvs. We already do that for other eros-os hosted lists. From shap@eros-os.org Mon Sep 17 15:25:07 2001 Received: from mail.eros-os.org (IDENT:root@EROS.CIS.UPENN.EDU [158.130.6.119]) by eros.cs.jhu.edu (8.11.0/8.11.0) with ESMTP id f8HJP7v05515; Mon, 17 Sep 2001 15:25:07 -0400 Received: from eros.cs.jhu.edu (IDENT:root@eros.cs.jhu.edu [128.220.223.245]) by mail.eros-os.org (8.9.3/8.9.3) with ESMTP id PAA01215; Mon, 17 Sep 2001 15:17:04 -0400 Received: from vmware (mikado.cs.jhu.edu [128.220.223.247]) (authenticated (0 bits)) by eros.cs.jhu.edu (8.11.0/8.11.0) with ESMTP id f8HJP6v05510; Mon, 17 Sep 2001 15:25:06 -0400 Message-ID: <059d01c13fae$86a145a0$021010ac@vmware> From: "Jonathan S. Shapiro" To: , , Date: Mon, 17 Sep 2001 15:25:35 -0400 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_059A_01C13F8C.FF698000" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4807.1700 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 Subject: [capidl] capidl alive again Sender: capidl-admin@mail.eros-os.org Errors-To: capidl-admin@mail.eros-os.org X-BeenThere: capidl@mail.eros-os.org X-Mailman-Version: 2.0beta5 Precedence: bulk List-Id: 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 = 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

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.

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:

=20 http://www.er= os-os.org/capidl-src/capidl-grammar.y

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.

If you wish to track capidl, subscribe = to the=20 capidl list via http://www.eros-os.org/m= ailman/listinfo --=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.

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.

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.

So the steps are:

1. Nail down the grammar.

2. Specify the semantics, where=20 needed.

3. Nail down the canonical=20 representation.

4. Implement back-ends that generate C, = XML (of=20 parse tree), XML (for docs), C++, Java.

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?

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

As to using XML output for the=20 documentation...

There are two main reasons to use XML = for=20 documentation in CapIDL.

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.

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.

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.

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.

------=_NextPart_000_059A_01C13F8C.FF698000-- From shap@eros-os.org Mon Sep 17 15:30:17 2001 Received: from mail.eros-os.org (IDENT:root@EROS.CIS.UPENN.EDU [158.130.6.119]) by eros.cs.jhu.edu (8.11.0/8.11.0) with ESMTP id f8HJUGv05793; Mon, 17 Sep 2001 15:30:17 -0400 Received: from eros.cs.jhu.edu (IDENT:root@eros.cs.jhu.edu [128.220.223.245]) by mail.eros-os.org (8.9.3/8.9.3) with ESMTP id PAA01323; Mon, 17 Sep 2001 15:22:13 -0400 Received: from vmware (mikado.cs.jhu.edu [128.220.223.247]) (authenticated (0 bits)) by eros.cs.jhu.edu (8.11.0/8.11.0) with ESMTP id f8HJUFv05786; Mon, 17 Sep 2001 15:30:15 -0400 Message-ID: <05b401c13faf$3c492da0$021010ac@vmware> From: "Jonathan S. Shapiro" To: , , , Date: Mon, 17 Sep 2001 15:30:40 -0400 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_05B1_01C13F8D.B51D9D00" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4807.1700 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 Subject: [capidl] change on capidl list Sender: capidl-admin@mail.eros-os.org Errors-To: capidl-admin@mail.eros-os.org X-BeenThere: capidl@mail.eros-os.org X-Mailman-Version: 2.0beta5 Precedence: bulk List-Id: This is a multi-part message in MIME format. ------=_NextPart_000_05B1_01C13F8D.B51D9D00 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MarkM just asked that we send the CVS notes to capidl-cvs instead, so = subscribe to both capidl and capidl-cvs if you want to see the CVS = reports. shap ------=_NextPart_000_05B1_01C13F8D.B51D9D00 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

MarkM just asked that we send the CVS = notes to=20 capidl-cvs instead, so subscribe to both capidl and capidl-cvs if you = want to=20 see the CVS reports.

shap

------=_NextPart_000_05B1_01C13F8D.B51D9D00-- From shap@eros-os.org Mon Sep 17 20:48:28 2001 Received: from mail.eros-os.org (IDENT:root@EROS.CIS.UPENN.EDU [158.130.6.119]) by eros.cs.jhu.edu (8.11.0/8.11.0) with ESMTP id f8I0mSv08159 for ; Mon, 17 Sep 2001 20:48:28 -0400 Received: from scaup.mail.pas.earthlink.net (scaup.mail.pas.earthlink.net [207.217.121.49]) by mail.eros-os.org (8.9.3/8.9.3) with ESMTP id UAA00741 for ; Mon, 17 Sep 2001 20:40:23 -0400 Received: from vmware (dialup-63.208.189.75.Dial1.Baltimore1.Level3.net [63.208.189.75]) by scaup.mail.pas.earthlink.net (EL-8_9_3_3/8.9.3) with ESMTP id RAA27147 for ; Mon, 17 Sep 2001 17:53:03 -0700 (PDT) Message-ID: <031001c13fdc$365dda80$021010ac@vmware> From: "Jonathan S. Shapiro" To: Date: Mon, 17 Sep 2001 20:52:34 -0400 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_030D_01C13FBA.AD78B300" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4807.1700 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 Subject: [capidl] Re: [EROS-Arch] capidl alive again Sender: capidl-admin@mail.eros-os.org Errors-To: capidl-admin@mail.eros-os.org X-BeenThere: capidl@mail.eros-os.org X-Mailman-Version: 2.0beta5 Precedence: bulk List-Id: This is a multi-part message in MIME format. ------=_NextPart_000_030D_01C13FBA.AD78B300 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable > Is there a reason you're using DTDs instead of schemas? There are three. 1. My best impression at this point is that a lot of users grok DTD's at this point, and there is a lot of support for using them, but most users don't yet grok schemas. 2. In particular, I haven't found any open source tools for validating = XML parse against a schema rather than a DTD. 3. I personally don't understand schemas, and I prefer to stick to = something I understand. All that said, I'm happy to consider schemas if you can point me to a succinct starting point for learning enough about them to get up to = speed. shap ------=_NextPart_000_030D_01C13FBA.AD78B300 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable > Is there a reason you're using DTDs instead = of=20 schemas?

There are three.

1. My best impression at this = point is=20 that a lot of users grok DTD's at
this point, and there is a lot of = support=20 for using them, but most users
don't yet grok schemas.

2. In=20 particular, I haven't found any open source tools for validating = XML
parse=20 against a schema rather than a DTD.

3. I personally don't = understand=20 schemas, and I prefer to stick to something
I understand.

All = that=20 said, I'm happy to consider schemas if you can point me to a
succinct = starting point for learning enough about them to get up to=20 speed.

shap

------=_NextPart_000_030D_01C13FBA.AD78B300-- From shap@eros-os.org Mon Sep 17 21:14:11 2001 Received: from mail.eros-os.org (IDENT:root@EROS.CIS.UPENN.EDU [158.130.6.119]) by eros.cs.jhu.edu (8.11.0/8.11.0) with ESMTP id f8I1EBv08306 for ; Mon, 17 Sep 2001 21:14:11 -0400 Received: from scaup.mail.pas.earthlink.net (scaup.mail.pas.earthlink.net [207.217.121.49]) by mail.eros-os.org (8.9.3/8.9.3) with ESMTP id VAA00796 for ; Mon, 17 Sep 2001 21:06:06 -0400 Received: from vmware (dialup-63.208.189.75.Dial1.Baltimore1.Level3.net [63.208.189.75]) by scaup.mail.pas.earthlink.net (EL-8_9_3_3/8.9.3) with ESMTP id SAA06363; Mon, 17 Sep 2001 18:18:34 -0700 (PDT) Message-ID: <033f01c13fdf$b12ce190$021010ac@vmware> From: "Jonathan S. Shapiro" To: "Karp, Alan" Cc: References: Date: Mon, 17 Sep 2001 21:17:29 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4807.1700 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 Subject: [capidl] Re: [EROS-Arch] capidl alive again Sender: capidl-admin@mail.eros-os.org Errors-To: capidl-admin@mail.eros-os.org X-BeenThere: capidl@mail.eros-os.org X-Mailman-Version: 2.0beta5 Precedence: bulk List-Id: > I've asked a friend who knows a lot more about the difference to reply. If > you don't get an answer by Monday, let me know. The main problem I know of > with DTDs is their limited expressiveness. > > _________________________ > Alan Karp Alan: suggest this conversation should copy capidl. DTDs definitely lack some important stuff, and in a couple of cases the expressive power they lack was foolish ommissions rather than true simplifications. The primary impediment to XML Schemas, at the moment, is that there doesn't appear to be a non-java open-source XML/XSLT processing suite that knows how to validate against xml schemas. libxml2 only does DTDs, and that settled only recently. I don't suppose that XML schema validation would be all that hard to add, but I'm not eager to bite off yet another project here. The blocker here is that the EROS build process cannot rely on Java, because I'm not going to pay sun for the privilege of a JDK port to native EROS. I think that the best solution for now is likely to turn out to be using a DTD and allowing for cutover to XML schemas when support for them is widely available in non-java form shap From markm@caplet.com Mon Sep 17 22:18:07 2001 Received: from mail.eros-os.org (IDENT:root@EROS.CIS.UPENN.EDU [158.130.6.119]) by eros.cs.jhu.edu (8.11.0/8.11.0) with ESMTP id f8I2I7v08657 for ; Mon, 17 Sep 2001 22:18:07 -0400 Received: from proxy4.ba.best.com (root@proxy4.ba.best.com [206.184.139.15]) by mail.eros-os.org (8.9.3/8.9.3) with ESMTP id WAA00844; Mon, 17 Sep 2001 22:10:01 -0400 Received: from caplet.caplet.com (sdn-as-001njpennP198.dialsprint.net [158.252.58.8]) by proxy4.ba.best.com (8.9.3/8.9.2/best.out) with ESMTP id TAA02743; Mon, 17 Sep 2001 19:21:20 -0700 (PDT) Message-Id: <5.1.0.14.2.20010917190452.0472d0b0@shell9.ba.best.com> X-Sender: erights@shell9.ba.best.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Mon, 17 Sep 2001 19:20:43 -0700 To: "Jonathan S. Shapiro" From: "Mark S. Miller" Subject: Re: [capidl] Re: [EROS-Arch] capidl alive again Cc: "Karp, Alan" , In-Reply-To: <033f01c13fdf$b12ce190$021010ac@vmware> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: capidl-admin@mail.eros-os.org Errors-To: capidl-admin@mail.eros-os.org X-BeenThere: capidl@mail.eros-os.org X-Mailman-Version: 2.0beta5 Precedence: bulk List-Id: The w3c-defined xml schemas are such a horrible disaster of complexity run amok that it's hard to see how anyone can take them seriously. Their one service to the world may be to slow further acceptance of XML. I recommend sticking with DTDs because they're well understood and simpler (though by no means simple). I also recommend that we define the subset of XML and DTDs that we'll use for this project. I could stand Minimal-XMLs + attributes. I could stand the Canonical-XML subset of XML, but without whitespace canonicalization of the input, and with namespaces, if allowed, used only in strict adherence to the Common-XML recommendations. (I'd rather disallow namespaces completely of course, but...) If we feel we must have a schema-like mechanism, please consider http://www.smallstd.org/smallschema/index.html or http://www.oasis-open.org/committees/relax-ng/ . The latter is quickly gaining respect in various corners of the XML community. It is a collaborative unification of TREX and RELAX, which were the previous well known decent schema proposals. Cheers, --MarkM From shap@eros-os.org Mon Sep 17 22:39:49 2001 Received: from mail.eros-os.org (IDENT:root@EROS.CIS.UPENN.EDU [158.130.6.119]) by eros.cs.jhu.edu (8.11.0/8.11.0) with ESMTP id f8I2dnv08933 for ; Mon, 17 Sep 2001 22:39:49 -0400 Received: from scaup.mail.pas.earthlink.net (scaup.mail.pas.earthlink.net [207.217.121.49]) by mail.eros-os.org (8.9.3/8.9.3) with ESMTP id WAA00918 for ; Mon, 17 Sep 2001 22:31:43 -0400 Received: from vmware (dialup-63.208.187.23.Dial1.Baltimore1.Level3.net [63.208.187.23]) by scaup.mail.pas.earthlink.net (EL-8_9_3_3/8.9.3) with ESMTP id TAA07813; Mon, 17 Sep 2001 19:44:21 -0700 (PDT) Message-ID: <003401c13fea$efeba6e0$021010ac@vmware> From: "Jonathan S. Shapiro" To: "Mark S. Miller" Cc: References: <5.1.0.14.2.20010917190452.0472d0b0@shell9.ba.best.com> Subject: Re: [capidl] Re: [EROS-Arch] capidl alive again Date: Mon, 17 Sep 2001 22:32:42 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4807.1700 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 Sender: capidl-admin@mail.eros-os.org Errors-To: capidl-admin@mail.eros-os.org X-BeenThere: capidl@mail.eros-os.org X-Mailman-Version: 2.0beta5 Precedence: bulk List-Id: > I also recommend that we define the subset of > XML and DTDs that we'll use for this project. I could stand Minimal-XMLs + > attributes. I could stand... We had previously agreed that the user could specify the DTD for the documentation input, which means that (a) we must support full XML, at least to the extent of being able to pass it through, and (b) we must support the namespaces proposal so as to keep the capidl namespace cleanly separated from the user-supplied documentation namespace. Neither of these, in practice, seems burdensome. Different projects will, of course, define documentation DTDs appropriate to their needs. If the right one for E is to use a MinXML type of DTD, then please by all means do so. The only real requirement on CapIDL here is that the XML parser support full XML. Given the level of wide acceptance, it's pretty clear that CapIDL should be build on Xalan, which already provides full XML. Xerces (the XSLT processor) provides full Xpath compatibility, so I assume that they got the semantics right to the extent that it is possible to do so. shap From shap@eros-os.org Tue Sep 18 11:10:13 2001 Received: from mail.eros-os.org (IDENT:root@EROS.CIS.UPENN.EDU [158.130.6.119]) by eros.cs.jhu.edu (8.11.0/8.11.0) with ESMTP id f8IFADv16435 for ; Tue, 18 Sep 2001 11:10:13 -0400 Received: from eros.cs.jhu.edu (IDENT:root@eros.cs.jhu.edu [128.220.223.245]) by mail.eros-os.org (8.9.3/8.9.3) with ESMTP id LAA00738 for ; Tue, 18 Sep 2001 11:02:04 -0400 Received: from vmware (mikado.cs.jhu.edu [128.220.223.247]) (authenticated (0 bits)) by eros.cs.jhu.edu (8.11.0/8.11.0) with ESMTP id f8IFA7v16430 for ; Tue, 18 Sep 2001 11:10:07 -0400 Message-ID: <00ee01c14054$1c903d50$021010ac@vmware> From: "Jonathan S. Shapiro" To: Date: Tue, 18 Sep 2001 11:10:54 -0400 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_00EB_01C14032.9550D690" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4807.1700 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 Subject: [capidl] Some corrections Sender: capidl-admin@mail.eros-os.org Errors-To: capidl-admin@mail.eros-os.org X-BeenThere: capidl@mail.eros-os.org X-Mailman-Version: 2.0beta5 Precedence: bulk List-Id: This is a multi-part message in MIME format. ------=_NextPart_000_00EB_01C14032.9550D690 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable The following notes correct/revise various things from yesterday in the = wake of a conversation with Mark Miller. Small item: I'm going to preserve the @crud syntax from JavaDoc. I reserve the right = to repair some quoting issues and not to support legacy syntaxes that = have been supersceded in more recent versions of JavaDoc. Mark made a compelling case for mindshare compatibility on this issue. ------=_NextPart_000_00EB_01C14032.9550D690 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

The following notes correct/revise = various things=20 from yesterday in the wake of a conversation with Mark = Miller.

Small item:

I'm going to preserve the @crud syntax = from=20 JavaDoc. I reserve the right to repair some quoting issues and not to = support=20 legacy syntaxes that have been supersceded in more recent versions of=20 JavaDoc.

Mark made a compelling case for = mindshare=20 compatibility on this issue.

------=_NextPart_000_00EB_01C14032.9550D690-- From shap@eros-os.org Tue Sep 18 11:20:14 2001 Received: from mail.eros-os.org (IDENT:root@EROS.CIS.UPENN.EDU [158.130.6.119]) by eros.cs.jhu.edu (8.11.0/8.11.0) with ESMTP id f8IFKEv16499; Tue, 18 Sep 2001 11:20:14 -0400 Received: from eros.cs.jhu.edu (IDENT:root@eros.cs.jhu.edu [128.220.223.245]) by mail.eros-os.org (8.9.3/8.9.3) with ESMTP id LAA00767; Tue, 18 Sep 2001 11:12:04 -0400 Received: from vmware (mikado.cs.jhu.edu [128.220.223.247]) (authenticated (0 bits)) by eros.cs.jhu.edu (8.11.0/8.11.0) with ESMTP id f8IFKDv16494; Tue, 18 Sep 2001 11:20:13 -0400 Message-ID: <00f901c14055$8401e8c0$021010ac@vmware> From: "Jonathan S. Shapiro" To: , Date: Tue, 18 Sep 2001 11:20:57 -0400 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_00F6_01C14033.FCD1C440" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4807.1700 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 Subject: [capidl] Concerning XML docs Sender: capidl-admin@mail.eros-os.org Errors-To: capidl-admin@mail.eros-os.org X-BeenThere: capidl@mail.eros-os.org X-Mailman-Version: 2.0beta5 Precedence: bulk List-Id: This is a multi-part message in MIME format. ------=_NextPart_000_00F6_01C14033.FCD1C440 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable [CapIDL related, out of context] The longest portion of my conversation with MarkM last night concerned = the commitment to XML. At one point, he was quite distressed about = committing to XML, I suspect because of issues in the content model = semantics. I would like to understand this issue better, and if somebody = knows of a *brief* summary I can read, I would be very appreciative. I = refer to the issues that have forced canonical XML to diverge, and to = the content model semantic gap between the "official" version and the = Xpath version of the content model. My opinion, in the absence of further information, is that the XML world = has no artistic aesthetic worth mentioning, and that there *are* = semantic problems in the spec, but that the cost of deviation exceeds = the cost of poor semantics in this area. We cannot -- and should not try to -- redirect the XML community as a = whole, and this means that we should be prepared to parse full XML = wherever XML is generated by (a) humans or (b) tools outside of our own = tool suite. Note that we do not need a validating parser for this, and = that non-validating parsers really aren't that complex. That said, I am all in favor of using a sensible, restricted subset of = XML for use by our own tools. The most reasonable subset is probably = minml with the follwing attributes (only) id so we can encode graphs idref so we can encode graphs Speaking for myself, I might also argue for: class so we can apply CSS to decently display the results. A.href (or something equivalent to href) so that we can express *outbound* links in minml. The issue here is that the content restrictions on element bodies (#PCDATA) are not quite the same as the restrictions for attributes, with the = result that off-the-shelf translators may not be able to reliably produce HTML entities without use of attributes for this purpose A.name (or equivalent) for the same reasons as above. Of these, I could contentedly yield on the A's, but the class attribute = might prove valuable for visualization so as to key presentation using = CSS. Jonathan ------=_NextPart_000_00F6_01C14033.FCD1C440 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

[CapIDL related, out of = context]

The longest portion of my conversation = with MarkM=20 last night concerned the commitment to XML. At one point, he was quite=20 distressed about committing to XML, I suspect because of issues in the = content=20 model semantics. I would like to understand this issue better, and if = somebody=20 knows of a *brief* summary I can read, I would be very appreciative. I = refer to=20 the issues that have forced canonical XML to diverge, and to the content = model=20 semantic gap between the "official" version and the Xpath version of the = content=20 model.

My opinion, in the absence of further = information,=20 is that the XML world has no artistic aesthetic worth mentioning, and = that there=20 *are* semantic problems in the spec, but that the cost of deviation = exceeds the=20 cost of poor semantics in this area.

We cannot -- and should not try to = -- redirect=20 the XML community as a whole, and this means that we should be prepared = to parse=20 full XML wherever XML is generated by (a) humans or (b) tools outside of = our own=20 tool suite. Note that we do not need a validating parser for this, and = that=20 non-validating parsers really aren't that complex.

That said, I am all in favor of using a = sensible,=20 restricted subset of XML for use by our own tools. The most reasonable=20 subset is probably minml with the = follwing=20 attributes (only)

id = so we can encode graphs

= idref so we=20 can encode graphs

Speaking for myself, I might also argue = for:

= class so we=20 can apply CSS to decently display the results.

= A.href (or=20 something equivalent to href) so that we can express

= *outbound*=20 links in minml. The issue here is that the

= content=20 restrictions on element bodies (#PCDATA) are not