There are schema definitions at C:\apache\cocoon-2.1\src\blocks\databases\samples\xsp\esql.xsd for esql C:\apache\cocoon-2.1\src\documentation\xdocs\drafts\sitemap-2.1-draft.xsd for *.xmap
Are these to be organised with the DTDs of this proposal? ----- Original Message ----- From: "Stefano Mazzocchi" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Cc: <[EMAIL PROTECTED]> Sent: Thursday, January 15, 2004 10:01 AM Subject: Re: [Proposal] add DTDs to Apache website > > On 15 Jan 2004, at 05:05, David Crossley wrote: > > > Joerg Heinicke wrote: > >> David Crossley wrote: > >> > >>> 3) The Forrest website is built using the "stable" version of > >>> Forrest (currently v0.5.1). So how will DTDs from the current > >>> CVS (v0.6-dev) get into the website CVS [3]? Manual copy? See 4). > >>> > >>> 4) If some committer changes the DTDs in CVS then they will be > >>> out-of-sync. Will committers remember to do the manual copy? See 3). > >> > >> I don't see this problem. On the one hand there are the older files > >> like > >> document 0.10 or 0.11 that won't be touched, on the other hand 0.12 > >> (or > >> is it already old too?) which is developed at the moment. You can't > >> make > >> incompatible changes for one version, otherwise you will break > >> possibly > >> thousands of documents out there. So only extensions are possible. > > > > Absolutely. I think that i got a bit mixed up with whatever i was > > trying to say in item 4. We need proper version control and we > > have a naming convention for that. > > > > Forrest has been careful not to introduce any incompatible changes. > > However, i think that we need to be more careful about adding even > > new optional stuff. Every change should be a totally new DTD version. > > > >> In > >> conclusion: the update cycle must not be once per minute, but maybe > >> once > >> per day or only week. Now what about having a cron job running on the > >> website server that checks out recent DTD versions? Forcing manual > >> work > >> that's critical and without much effort automatically doable sounds > >> not > >> that good. > > > > Good idea. Nicola Ken suggested something similar. > > Ok, a little more .htaccess magic: > > # First, proxy the content straight out of ViewCVS > ProxyPass /forrest/ > http://cvs.apache.org/viewcvs.cgi/*checkout*/xml-forrest/src/core/ > context/resources/schema/dtd/ > ProxyPassReverse /forrest/ > http://cvs.apache.org/viewcvs.cgi/*checkout*/xml-forrest/src/core/ > context/resources/schema/dtd/ > > # Now, since ViewCVS is pretty slow, make sure you cache it > CacheEnable mem /forrest/ > > # for a day > CacheDefaultExpire 86400 > MCacheSize 4096 > MCacheMaxObjectCount 100 > MCacheMinObjectSize 1 > MCacheMaxObjectSize 2048 > > # and in case your client is a good web citizen, tell the proxies down > the road > # to avoid calling us since we guarantee the content is fresh for a day > ExpiresActive On > ExpiresDefault "access plus 1 day" > > > -- > Stefano, who has been waiting for some 18 months for somebody else to > come up with the idea of having forrest pregenerating the .htaccess > file to do some sort of poor-man multichannel or content negotiation, > but has lost hope so it's time to inject notion in the system. > >
