Hi, sorry for the delay. Some hardware failure of my machine had troubled me for a week...
Gabor Kovesdan <[EMAIL PROTECTED]> wrote in <[EMAIL PROTECTED]>: ga> Good idea. And we can have a website.ent in share/sgml, just like ga> articles.ent and books.ent to easily pull in the necessary ga> entities. About this I have more ideas as I've been looking at the ga> opportunities with XML. I already have something in a local repo, but ga> it's highly wip. I think that doc/en_US.ISO8859-1/share/sgml should ga> only contain some "glue" .ent files, for example imho newsgroups.ent ga> should go into doc/share/sgml so that translators can use them in an ga> early phase of the translation or simply reuse them if there is ga> something to reuse. Agreed. ga> The idea seems good, but with the DTD I have some ideas and doubts: ga> - We have the location data in ports/astro/xearth, in this way we would ga> - introduce one more duplication ga> - We have the birthday data in src/usr.bin/calendar, which may not be a ga> - problem as it cannot change Yes, I have noticed them. I think a way that generating files for calendar and xearth from the XML file works. How about? ga> - If someone leaves core and returns, or simply resigns his commit bit ga> - and returns the from-to attributes cannot be precise. Or maybe we ga> - could for example merge 1995-1997 and 1999-2000 as 1995-2000? Ah, it is possible to add two or more <bit role="src"> tags in that case, for example. When two periods can be merged, it can be calculated from them by using XLST stylesheet. ga> - There might be a website or comment element or attribute to put ga> - personal websites or additional info (e.g. we have at least 2 deceased ga> - committers) Yes, additional elements for such purpose would be useful. -- | Hiroki SATO
pgpXcimx4Ta7w.pgp
Description: PGP signature
