From: Brian W. <bw...@st...> - 2002-08-26 02:25:20
|
I am afraid I have dropped off the radar a bit on this one, so sorry in advance for this coming out of the blue a bit. Anyway - I was going through the archives and I stumbled across this post, which I had missed: >According to J. op den Brouw: > > It's a nice patch for those who cannot use syslog facilities, but > > the patch removes the syslog logging feature. It would be nice > > to select one of them (or have them both) on compile or run time > > basis. > > > > It's also a patch against 3.1.6. It would be nice if there's a > > patch for 3.2.0b4-xxxx too. > > > > Furthermore, I see a flock() call somewhere. AFAIK, different > > OS-es use different names and parameter lists. Example > > > > HP-UX: int lockf(int fildes, int function, off_t size); > > Linux 2.2: int flock(int fd, int operation); > >I hadn't noticed when I looked at the patch that it completely removed >the ability to log to syslog(). That's one more reason to reject >it for 3.1.x. I rejected it over concerns about portability, as you >pointed out. I don't think it's appropriate for inclusion in 3.1.7 >either for that reason. Ok. 1) The patch does not remove the ability to do syslog. In my notes that go with the patch it says: > * logging_file ( Default: none ) > > If this is set to "none", then it will log using syslog, otherwise > this will be assumed to be the path to the log file The whole way it is set up, it uses the existing default behaviour if it isn't explicitly activated. 2) If the issue is the portability of flock, would it be acceptable if I changed it over to using fcntl? (Mr Google threw up the follwoing page which says that "fcntl() is the only POSIX-compliant locking mechanism, and is therefore the only truly portable lock" http://www.erlenstar.demon.co.uk/unix/faq_3.html ) 3) It should be simple enough to create a patch that works with 3.2.x, judging by a quick look at the latest Display.cc in the CVS repository. I *would* like to get it rolled into 3.1.x if I can. I am more than willing to make any changes required to make this happen. Regs Brian White ------------------------- Brian White Step Two Designs Pty Ltd Knowledge Management Consultancy, SGML & XML Phone: +612-93197901 Web: http://www.steptwo.com.au/ Email: bw...@st... Content Management Requirements Toolkit 112 CMS requirements, ready to cut-and-paste |
From: Gilles D. <gr...@sc...> - 2002-09-05 23:11:19
|
According to Brian White: > >According to J. op den Brouw: > > > It's a nice patch for those who cannot use syslog facilities, but > > > the patch removes the syslog logging feature. It would be nice > > > to select one of them (or have them both) on compile or run time > > > basis. > > > > > > It's also a patch against 3.1.6. It would be nice if there's a > > > patch for 3.2.0b4-xxxx too. > > > > > > Furthermore, I see a flock() call somewhere. AFAIK, different > > > OS-es use different names and parameter lists. Example > > > > > > HP-UX: int lockf(int fildes, int function, off_t size); > > > Linux 2.2: int flock(int fd, int operation); > > > >I hadn't noticed when I looked at the patch that it completely removed > >the ability to log to syslog(). That's one more reason to reject > >it for 3.1.x. I rejected it over concerns about portability, as you > >pointed out. I don't think it's appropriate for inclusion in 3.1.7 > >either for that reason. > > Ok. > > 1) The patch does not remove the ability to do syslog. In my notes > that go with the patch it says: > > > * logging_file ( Default: none ) > > > > If this is set to "none", then it will log using syslog, otherwise > > this will be assumed to be the path to the log file > > > The whole way it is set up, it uses the existing default > behaviour if it isn't explicitly activated. Good. I didn't recall seeing any red flags go up in regards to this last time I looked at your patch, but that was a while ago. I didn't review your patch when Jesse made this statement, so I took his word for it. > 2) If the issue is the portability of flock, would it be > acceptable if I changed it over to using fcntl? > > (Mr Google threw up the follwoing page which says that "fcntl() is the > only POSIX-compliant locking mechanism, and is therefore the only > truly portable lock" > > http://www.erlenstar.demon.co.uk/unix/faq_3.html > ) Well, while going with POSIX-compliant locking would help with portability, I'm not sure all systems currently supported by 3.1.x are fully POSIX-compliant either, so it may be that some only support flock(), or even perhaps no locking at all. Some configure tests for various locking schemes should be implemented, so the code uses what the system provides, or no locking at all if nothing appropriate is found. > 3) It should be simple enough to create a patch that works with 3.2.x, > judging by a quick look at the latest Display.cc in the CVS repository. > > I *would* like to get it rolled into 3.1.x if I can. I am > more than willing to make any changes required to make this > happen. I think it would be good to see this in the 3.2 CVS tree, with the appropriate configure tests. I'm still a bit lukewarm on the addition of the "init" input parameter to htsearch. It seems the absense of a "page" parameter would mean the same thing, wouldn't it? As for 3.1.x, though, here are my thoughts. I'm quite adament about not wanting to put out a 3.1.8 release. So, that means I have to be very adament about getting 3.1.7 right, with no new bugs or portability problems. To do that, I think I'm going to need to put my foot down as far as the feature freeze, and insist that only bug fixes go into 3.1.7, and no new features. The only discussed new feature for 3.1.7 that I haven't completely ruled out yet is location_factor, because it's tied to some bug fixes in WordList::Word() anyway, and had been planned for 3.1.6 but fell through the cracks. I may drop this attribute anyway, and stick to just bug fixes. -- Gilles R. Detillieux E-mail: <gr...@sc...> Spinal Cord Research Centre WWW: http://www.scrc.umanitoba.ca/ Dept. Physiology, U. of Manitoba Winnipeg, MB R3E 3J7 (Canada) |
From: Joe R. J. <jj...@cl...> - 2002-09-06 00:53:30
|
On Thu, 5 Sep 2002, Gilles Detillieux wrote: > Date: Thu, 5 Sep 2002 18:10:53 -0500 (CDT) > From: Gilles Detillieux <gr...@sc...> > To: Brian White <bw...@st...> > Cc: htd...@li... > Subject: Re: [htdig-dev] Adjustable logging patch. > > As for 3.1.x, though, here are my thoughts. I'm quite adament about > not wanting to put out a 3.1.8 release. So, that means I have to be > very adament about getting 3.1.7 right, with no new bugs or portability > problems. To do that, I think I'm going to need to put my foot down as > far as the feature freeze, and insist that only bug fixes go into 3.1.7, > and no new features. The only discussed new feature for 3.1.7 that I > haven't completely ruled out yet is location_factor, because it's tied > to some bug fixes in WordList::Word() anyway, and had been planned for > 3.1.6 but fell through the cracks. I may drop this attribute anyway, > and stick to just bug fixes. Would you please list the patches you have already committed to CVS, and those you may, so that we can carry over the rest as patches to 3.1.7 folder. Here is the list as of: Thu Sep 5 17:38:47 PDT 2002: Patch # of downloads ----- -------------- ssl.9 193 timet_enddate.1 182 Makefile.0 78 documentation.1 68 metadate.0 65 redirect.0 51 documentation.2 50 NUL.0 47 AdjustableLoggingPatch.tar.gz 44 fileSpace.1 42 titleSpace.0 36 multiple-noindex.1 34 Date-viewing.0 32 time_t.0 27 gcc-3.1.0 22 ExecutionTime.0 9 ExternalParser-max_doc_size.0 7 htnotifyNull.0 6 Regards, Joe -- _/ _/_/_/ _/ ____________ __o _/ _/ _/ _/ ______________ _-\<,_ _/ _/ _/_/_/ _/ _/ ......(_)/ (_) _/_/ oe _/ _/. _/_/ ah jj...@cl... |
From: Gilles D. <gr...@sc...> - 2002-09-06 14:48:44
|
According to Joe R. Jah: > Would you please list the patches you have already committed to CVS, and > those you may, so that we can carry over the rest as patches to 3.1.7 > folder. Actually, I haven't begun committing changes to CVS yet. As for 3.1.6, I'll probably wait until I have a sufficiently large and complete to-do list, and a good chunk of time I can devote to the task (which I don't have now), and then get a flurry of commits happening. All I have right now is a to-do list of 23 bug fixes, some of which exist in patches and some of which need to be written still. I also need to go through the set of existing patches to see what's ready to use as-is, what needs tweaking/configure test/documentation, and what I'll exclude. > Here is the list as of: Thu Sep 5 17:38:47 PDT 2002: > > Patch # of downloads > ----- -------------- > ssl.9 193 > timet_enddate.1 182 > Makefile.0 78 > documentation.1 68 > metadate.0 65 > redirect.0 51 > documentation.2 50 > NUL.0 47 > AdjustableLoggingPatch.tar.gz 44 > fileSpace.1 42 > titleSpace.0 36 > multiple-noindex.1 34 > Date-viewing.0 32 > time_t.0 27 > gcc-3.1.0 22 > ExecutionTime.0 9 > ExternalParser-max_doc_size.0 7 > htnotifyNull.0 6 Offhand, I'd break them down thus... Include as-is Leave out ------------- --------- Date-viewing.0 AdjustableLoggingPatch.tar.gz ExternalParser-max_doc_size.0 ExecutionTime.0 Makefile.0 multiple-noindex.1 documentation.1 ssl.9 documentation.2 titleSpace.0 gcc-3.1.0 metadate.0 redirect.0 time_t.0 timet_enddate.1 Unsure/needs work ----------------- fileSpace.1 (new feature, needs docs, but simple/clean/portable & in demand) NUL.0 (needs config attribute & docs, adds overhead) htnotifyNull.0 (still has problems with in.bad() handling) For those who are interested, my current, sketchy to-do list for 3.1.7 is... - back out Gabriele's CVS changes of Aug 13 - fix "not HTML" error message to something like "unknown Content-type". + server_wait_time is currently misspelled in cf_byname.html + string list description explains quoted string list in cf_types.html + htmerge -m is unclear (fixed in maindocs) + Marchand's patch to htsearch/Display.cc (fix enddate bug) + Marchand's patch to Makefile.config.in (use DEFS) + fix parsedcdate() in Retriever.cc to allow '-' after year - fix parsedcdate() in Retriever.cc to handle server's local timezone + "dc.date.modified" handling patch (May 17) - handle -ve scores and/or locations in WordList::Word() - fix parsers not to overflow location calc (find e-mail about this) - handle location_factor attr. in WordList::Word(), check bounds - checks for -ve scores in Display.cc - better handling of multimatch_factor, using a new count field in DocMatch - keep docdb records for noindex docs, just not words, so updates check these - don't delete ANCHOR just because it's not in excerpt - better handling of sup & sub tags in HTML.cc, optionally treat as punctuation - new catdoc link: http://www.ice.ru/~vitus/catdoc/ in contrib/* parsers - less verbose output from htnotify -v, require 2 or more v's for that - Martin Vorlaender's VMS patches + patch #548448 dealing with unsigned time_t (Apr 25) - handle nulls in text/* files (convert to space) where + means fixed in maindocs or a complete patch, and - means needs work. As you can see, my to-do list and the list of patches I want aren't even mutually complete, though most patches I want are mentioned in the to-do list. I've no doubt missed some things on my list that have been discussed as important/urgent before, but never got around to noting them. If anyone wants to help complete the list, or better yet knock off (i.e. implement) some items on the list, more power to you. -- Gilles R. Detillieux E-mail: <gr...@sc...> Spinal Cord Research Centre WWW: http://www.scrc.umanitoba.ca/ Dept. Physiology, U. of Manitoba Winnipeg, MB R3E 3J7 (Canada) |
From: Brian W. <bw...@st...> - 2002-09-06 01:33:41
|
At 09:10 6/09/2002, Gilles Detillieux wrote: > > 2) If the issue is the portability of flock, would it be > > acceptable if I changed it over to using fcntl? > > > > (Mr Google threw up the follwoing page which says that "fcntl() is the > > only POSIX-compliant locking mechanism, and is therefore the only > > truly portable lock" > > > > http://www.erlenstar.demon.co.uk/unix/faq_3.html > > ) > >Well, while going with POSIX-compliant locking would help with >portability, I'm not sure all systems currently supported by 3.1.x >are fully POSIX-compliant either, so it may be that some only support >flock(), or even perhaps no locking at all. Some configure tests for >various locking schemes should be implemented, so the code uses what >the system provides, or no locking at all if nothing appropriate is found. I already have "locked" and "unlocked" versions of the code, managed by an #ifdef - I would just have to add a -D__NO_FILE_LOCKING__ or something like that. I assume this means I would need to create a patch for the configure script - any tips on how to do that? Is that monster *really* maintained solely by hand or is there some tools for it? > > 3) It should be simple enough to create a patch that works with 3.2.x, > > judging by a quick look at the latest Display.cc in the CVS repository. > > > > I *would* like to get it rolled into 3.1.x if I can. I am > > more than willing to make any changes required to make this > > happen. > >I think it would be good to see this in the 3.2 CVS tree, with the >appropriate configure tests. I'm still a bit lukewarm on the addition >of the "init" input parameter to htsearch. It seems the absense of a >"page" parameter would mean the same thing, wouldn't it? You know, I hadn't even thought of that. The only disadvantage to it is that it isn't explicit - I can see someone setting "Page=1" for their initial search and wondering why their logging doesn't work. The only way around this would be documentation, with notes 1) Where the "page" parameter is discuseed 2) Where the logging attributes are discussed 3) In the FAQs Otherwise - Yes! Perfect! >As for 3.1.x, though, here are my thoughts. I'm quite adament about >not wanting to put out a 3.1.8 release. So, that means I have to be >very adament about getting 3.1.7 right, with no new bugs or portability >problems. To do that, I think I'm going to need to put my foot down as >far as the feature freeze, and insist that only bug fixes go into 3.1.7, >and no new features. The only discussed new feature for 3.1.7 that I >haven't completely ruled out yet is location_factor, because it's tied >to some bug fixes in WordList::Word() anyway, and had been planned for >3.1.6 but fell through the cracks. I may drop this attribute anyway, >and stick to just bug fixes. Ok - my desire to get it into 3.1.x is based around the fact that we have installed 3.1.6 at a large client site, with the AdjustableLogging patch installed. In fact, it was written for their installation. It makes long term support slightly easier if the product is *fully* off the shelf. However, that said - getting it into the 3.2 CVS tree means by the time it ever becomes a genuine issue, a stable 3.2 release should be available for use. I would be happy with that. >-- >Gilles R. Detillieux E-mail: <gr...@sc...> >Spinal Cord Research Centre WWW: http://www.scrc.umanitoba.ca/ >Dept. Physiology, U. of Manitoba Winnipeg, MB R3E 3J7 (Canada) ------------------------- Brian White Step Two Designs Pty Ltd Knowledge Management Consultancy, SGML & XML Phone: +612-93197901 Web: http://www.steptwo.com.au/ Email: bw...@st... Content Management Requirements Toolkit 112 CMS requirements, ready to cut-and-paste |
From: Brian W. <bw...@st...> - 2002-09-06 02:50:47
|
I was looking at defaults.cc and I was wondering if it might be better managing the info as an XML file and then using that as a basis for generating defaults.cc and the HTML docs. The fields are struct ConfigDefaults { char *name; // Name of the attribute char *value; // Default value char *type; // Type of the value (string, integer, boolean) char *programs; // Whitespace separated list of programs/modules using this attribute char *block; // Configuration block this can be used in (can be blank) char *version; // Version that introduced the attribute char *category; // Attribute category (to split documentation) char *example; // Example usage of the attribute (HTML) char *description; // Long description of the attribute (HTML) }; I can see programming uses for name, value, type and maybe programs. I assume all the rest is just for documentation It would be simple enough to write a perl script that extracted the necesary fields to create defaults.cc, that only had what was actually needed for the program, and then something a bit cleverer written to create the HTML pages. ( I just noticed the perl script that uses defaults.cc to generate the doc pages ) Advantages * It would put all the default info into a much easier to edit and documentable format * It would make it much clearer which values were required in the code and which were there for documentation. * It would reduce the size of the executable by about 80000 characters ( 80K or maybe 160 K) Disadvantages * Part of the build process for exexcutabe would require perl to exist * The current system, be it a bit clunky to my eyes, does work, and does solve the problem of trying to maintain concurrently the code version and the documentation version of the attributes. * After rabbiting on like this I now have to decide if I willing to put my money where my mouth is..... Regs Brian ------------------------- Brian White Step Two Designs Pty Ltd Knowledge Management Consultancy, SGML & XML Phone: +612-93197901 Web: http://www.steptwo.com.au/ Email: bw...@st... Content Management Requirements Toolkit 112 CMS requirements, ready to cut-and-paste |
From: Brian W. <bw...@st...> - 2002-09-09 01:15:43
|
Ok. I will volunteer to do this. I'll sketch up a mini-design and post it here. If I can take you up on you offer of creating an intial version of the xml file, that would be great. Regs Brian At 00:46 7/09/2002, Geoff Hutchison wrote: >On Fri, 6 Sep 2002, Brian White wrote: > > > I was looking at defaults.cc and I was wondering if > > it might be better managing the info as an XML file > > and then using that as a basis for generating > > defaults.cc and the HTML docs. > >Yes, this would actually be quite wonderful. Currently, it's hard to >"validate" changes you make to defaults.cc. It's also a minor pain to >insert and format HTML, since it has to be properly escaped. (No, it's not >a big deal, but XML would obviously be easier.) > > > Disadvantages > > * Part of the build process for exexcutabe would require > > perl to exist > >No, not really. We have lots of "autogenerated" files in 3.2. You'd only >need Perl if you modified defaults.xml and needed to generate the new >defaults.cc. > > > * After rabbiting on like this I now have to decide > > if I willing to put my money where my mouth is..... > >Yes, now that's the question. :-) > >Formatting defaults.cc into defaults.xml isn't hard and I'd be glad to do >that with some emacs macros. But I'd be glad to accept this change if you >(or someone) will write the defaults_generate.pl script. Ideally the >script would have some nice error-checking to tell you if you've left out >a field, etc. > >-- >-Geoff Hutchison >Williams Students Online >http://wso.williams.edu/ > > > >------------------------------------------------------- >This sf.net email is sponsored by: OSDN - Tired of that same old >cell phone? Get a new here for FREE! >https://www.inphonic.com/r.asp?r=sourceforge1&refcode1=vs3390 >_______________________________________________ >htdig-dev mailing list >htd...@li... >https://lists.sourceforge.net/lists/listinfo/htdig-dev ------------------------- Brian White Step Two Designs Pty Ltd Knowledge Management Consultancy, SGML & XML Phone: +612-93197901 Web: http://www.steptwo.com.au/ Email: bw...@st... Content Management Requirements Toolkit 112 CMS requirements, ready to cut-and-paste |
From: Gilles D. <gr...@sc...> - 2002-09-06 14:59:05
|
According to Brian White: > At 09:10 6/09/2002, Gilles Detillieux wrote: > >Well, while going with POSIX-compliant locking would help with > >portability, I'm not sure all systems currently supported by 3.1.x > >are fully POSIX-compliant either, so it may be that some only support > >flock(), or even perhaps no locking at all. Some configure tests for > >various locking schemes should be implemented, so the code uses what > >the system provides, or no locking at all if nothing appropriate is found. > > I already have "locked" and "unlocked" versions of the code, managed by > an #ifdef - I would just have to add a -D__NO_FILE_LOCKING__ or something > like that. Yes. Ideally, though, it would be automated via configure tests. For example, you test for the flock() call and define HAVE_FLOCK in htconfig.h. Then the code uses #ifdef HAVE_FLOCK. Similarly, you define something like HAVE_FCNTL_LOCK if that capability exists. That test is a bit more complex, as it's not just testing for the existance of a library function. > I assume this means I would need to create a patch for the configure > script - any tips on how to do that? Is that monster *really* maintained > solely by hand or is there some tools for it? It's generated from configure.in by the autoconf program. So, configure.in is the monster we maintain by hand, which isn't quite as big and scary as the configure script itself. Still, you need to learn enough about autoconf to get by, which is more than I know at this point. > > > 3) It should be simple enough to create a patch that works with 3.2.x, > > > judging by a quick look at the latest Display.cc in the CVS repository. > > > > > > I *would* like to get it rolled into 3.1.x if I can. I am > > > more than willing to make any changes required to make this > > > happen. > > > >I think it would be good to see this in the 3.2 CVS tree, with the > >appropriate configure tests. I'm still a bit lukewarm on the addition > >of the "init" input parameter to htsearch. It seems the absense of a > >"page" parameter would mean the same thing, wouldn't it? > > You know, I hadn't even thought of that. The only disadvantage to it > is that it isn't explicit - I can see someone setting "Page=1" for their > initial search and wondering why their logging doesn't work. The only > way around this would be documentation, with notes > > 1) Where the "page" parameter is discuseed > 2) Where the logging attributes are discussed > 3) In the FAQs > > Otherwise - Yes! Perfect! Not to mention writing attrs.html entries (and links in cf_by????.html) for all the new attributes. This is of course easier in 3.2. -- Gilles R. Detillieux E-mail: <gr...@sc...> Spinal Cord Research Centre WWW: http://www.scrc.umanitoba.ca/ Dept. Physiology, U. of Manitoba Winnipeg, MB R3E 3J7 (Canada) |
From: Brian W. <bw...@st...> - 2002-10-08 02:44:34
|
Geoff, I am still working on, but it has gone on the backburner a bit recently. I must confess, I ended up generating my own initial version, which I did using some a C for loop - I decided the C parser was the best way to parse a C data structure! I was thinking that * defaults.xml and defaults.dtd should go in htcommon * the perl script for generating defaults.cc should also go in htcommon. This should be very small and should assume that defaults.xml is valid. This then obviates the need for an XML parser to be present when rebuilding the code * the code for generating the HTML documentation pages should include proper XML validation The biggest issue I have at the moment is - how to cope with the structure descriptions, which are currently HTML snippets. There are three options: 1) Store as HTML snippets, but translate <,> and & to <,> and & - this will work, but I can tell you it is horrible to maintain by hand! 2) Store as HTML snippets, but escaped by CDATA sections 3) Include some capacity for markup in the XML. What I would like to do is include some abstraction for links to other htdig elements such as attributes, eg: <ref type="attr">valid_extensions</ref> instead of <a href="#valid_extensions">valid_extensions</a> which makes the data much more useful, but if I do that it prevents option (2). This would make the obvious choice option (3) - but then what markup do you allow? Anyway - here is my proposed DTD, which uses a very cut down HTML for markup. Any thoughts would be appreciated. <!DOCTYPE HtdigAttributes [ <!ELEMENT HtdigAttributes ( attribute+ ) > <!-- ConfigVar element is data set for each configuration variable. Attributes: name : Variable Name type : Type of Variable programs : Whitespace separated list of programs/modules using this attribute block : Configuration block this can be used in ( optional ) version : Version that introduced the attribute category : Attribute category (to split documentation) --> <!ELEMENT attribute( default, ( nodocs | (example, description ) ) > <!ATTLIST attribute name CDATA #REQUIRED type string|integer|boolean) "string" programs CDATA #REQUIRED block CDATA #IMPLIED version CDATA #REQUIRED category CDATA #REQUIRED > <!ELEMENT default (#PCDATA) > <!ATTLIST default configmacro (true|false) "false" > <!-- Basically a flag that suppresses documentation --> <!ELEMENT nodocs EMPTY> <!ELEMENT example (#PCDATA) > <!ENTITY % paratext "#PCDATA|em|strong|a|ref" > <!ENTITY % text "%paratext;|table|p|br|ol|ul|dl|codeblock" > <!ELEMENT description (%paratext;) > <!ELEMENT p (%paratext;)* > <!ELEMENT br EMPTY > <!ELEMENT ol (li+) > <!ELEMENT ul (li+) > <!ELEMENT li (%text;)* > <!ELEMENT table (tr+) > <!ELEMENT tr (td|th)+ > <!ELEMENT td (%text;)* > <!ELEMENT th (%text;)* > <!ATTLIST table border CDATA #IMPLIED width CDATA #IMPLIED > <!ATTLIST td align ( <!ELEMENT dl (dt|dd)+ > <!ELEMENT dt (%paratext;)* > <!ELEMENT dd (%text;)* > <!ELEMENT strong (%text;)* > <!ELEMENT em (%text;)* > <!ELEMENT a (%text;)* > <!ATTLIST a href CDATA #REQUIRED > <!ELEMENT ref (#PCDATA)* > ]> What I was going to suggest was that the int main() { for (int i = 0; defaults[i].name; i++) { printf( "<ConfigVar name=\"%s\" type=\"%s\" sinceversion=\"%s\" programs=\"%s\" \n" " configblock=\"%s\" \n" " category=\"%s\" >\n" " <default>%s</default>\n" " <example>%s</example>\n" " <description>%s </description>\n" "</ConfigVar>\n\n", defaults[i].name, defaults[i].type, defaults[i].version, defaults[i].programs, defaults[i].block, defaults[i].category, defaults[i].value, defaults[i].example, defaults[i].description ); } return 0; } It has gone a bit on the backburner recently, however it is still in the pipeline. I would certainly not halt changes to defaults.cc - we just come up with a final one at some point. There are several issues I have come across so far 1) Is there an XML parser available? This is not something that should be assumed - what I was going to suggest is a very basic script that generates defaults.cc that assumes that defaults.xml is valid, with a more full validating version that generates the HTML pages. 2) Where do we put it in the hierachy - it is used in both the 2) How do we include structured documnetation sninppets? There are kind of three ways to do a) HTML snippets escaped by entities - ie, have the documentation as a snippet of HTML, but with every "<", ">" and "&" translated to "<" , ">" and "&". This will work, but is as ugly as sin to try and maintain. b) HTML snippets escaped by CDATA marked sections c) One issue I realised is that attempting to use At 08:06 5/10/2002, Geoff Hutchison wrote: >A long time ago, in a thread far away... >http://www.geocrawler.com/archives/3/8825/2002/9/0/9520602/ > >Brian said: > > I was looking at defaults.cc and I was wondering if > > it might be better managing the info as an XML file > > and then using that as a basis for generating > > defaults.cc and the HTML docs. > >And I said: > > Formatting defaults.cc into defaults.xml isn't hard and I'd be glad to > > do that with some emacs macros. > >OK, I saw that on my TODO list today and added a defaults.xml to the >mainline CVS. It's also gzip'ed and attached to this e-mail. It's a first >draft, so to speak and I'm not entirely sure it's all well-formed XML or >that the DTD is set. So please make suggestions. > >However, I thought I'd pass this back to Brian--are you still willing to >write a script that'll generate a minimal defaults.cc? If so, I'll work on >the XML file a bit more--I need to make sure nothing was deleted by my >emacs slicing. >-Geoff ------------------------- Brian White Step Two Designs Pty Ltd Knowledge Management Consultancy, SGML & XML Phone: +612-93197901 Web: http://www.steptwo.com.au/ Email: bw...@st... Content Management Requirements Toolkit 112 CMS requirements, ready to cut-and-paste |