Colin Paul Adams wrote: > I've been busy today looking at the sitemap DTD, as it is an open > issue on the todo list.
Thanks for doing this important work. I just checked your draft DTD into 2.1-dev CVS. We definitely need something to validate sitemaps with, whether that be DTD, WXS, or RNG. > I have produced a version 0.3 of the dtd, against which all of the > sitemaps in the src tree now validate, except for the lint > sitemap. Since this purports to be an example of what is and what is > NOT valid, it MUST not validate. However some things in there which > purport to be valid do not validate. I decided not to tackle this, as > the very first item that did not validate was a tag named > unknown-tag. The idea being that a component configuration can have > any tags. > However, since each element must be declared in the DTD, this can > never validate - there must be a finite set of possible tags. > So the components could be declared to have ANY content, but I chose > to be more specific. I think this needs discussing. It does. Please start a new email thread for that. You would have noticed that the DTD was already relaxing a lot of constraints, just to get sitemaps to parse. Now that things are defined we can start tightening the rules. > I did change several of the sitemaps Please send patches for anything that needs fixing. > - purely by re-ordering the > contents of the map:components element so that all the sub-elements > were in a fixed order. This means I can validate that there is only > one of each component list present. The alternative is to allow any > order, but allow repeats. I don't know which is best. I presume that only one of each component is allowed (though i do not know the Cocoon code well enough to say). I vote +1 for re-arranging the current sitemaps so that components are in the order specified by the DTD. We can always change that constraint later. This gets the DTD into action now and may speed its development. > Clearly DTDs are designed for documents, not programming > declarations. A schema would be more useful than a DTD. The sitemap will get too complicated for DTDs as time goes by. However, a DTD is still useful now. Also, having a well-defined DTD will mean that we can generate a reliable Relax NG grammar from it (should we choose to go that way). There is also a draft WXS (W3C XML Schema) at src/documentation/xdocs/drafts/sitemap-2.1-draft.xsd I do not know its status, but see http://marc.theaimsgroup.com/?l=xml-cocoon-users&m=102338126329025 > My emphasis was on getting the sitemaps to validate, as I don't know > Cocoon nearly well enough to know what the DTD OUGHT to look like. I > have made a lot of comments pre-fixed with CPA throughout the DTD. I have added a few comments to yours.. When i made earlier attempts at a DTD, i struck the same problem as you - what *should* the rules be. It is very hard because design seems to happen on the listserver and in the code, but not reflected in the DTD. Then months later some of us try to catch-up. This situation probably arises because XML validation is not yet a core job of Cocoon. Therefore the DTD is not seen to be crucial. I would like to see validation of *.xmap and *.xconf during the build process at least. It would be better if there was a Cocoon component that did general validation. It could then process its own configuration files during startup and upon change to be sure that the framework is reliable. > Now, do I post the DTD to this mailing list as an attachment? > Since I'm not sure if that is allowed or not, I've put it on my web > site for comments: > http://www.colina.demon.co.uk/sitemap-v03.dtd > -- > Colin Paul Adams > Preston Lancashire Posting such stuff to Bugzilla is best, so that the work does not risk getting lost. http://xml.apache.org/cocoon/howto/howto-bugzilla.html By the way, i used OpenSP with your new sitemap-v03.dtd against the documentation/sitemap.xmap ... No errors from the DTD but a validation error with attributes of map:pipeline Sorry, no time to investigate now. --David --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
