On Mon, 11 Sep 2006, Ross Gardler wrote: > >>>> A better approach would be to process the XIncludes before validation, > >>>> stripping off the xlmns:xi attribute from the document element and > >>>> replacing xi:includes with whatever they resolve to. This should be > >>>> cheaper than it might seem: unless the xmlns:xi is present, the > >>>> document is simply handed on to the validator untouched. > >>> > >>> I can't see an easy way of doing this as, in many cases, the included > >>> content is generated by Forrest. In fact, this would be a problem if the > >>> parser were doing the includes. > >> > >> I am baffled. How would it be a problem if the parser was doing the > >> XIncludes? > > > > David points out in another message that the validate-xdocs is done > > prior to Forrest doing any transformations on content, it only validates > > the *source* documents.
Yes. Now think carefully about what you are saying. Validation is against the DTD, say document-v20.dtd. This is validation of the source document. As it stands, if that source document has any xs:includes in it, it is rejected by the validator. What you are saying is that when (some?) source documents are translated into internal format, Forrest adds xi:includes, and the transformed documents would not validate. That is, Forrest's internal format is not compliant with document-v20.dtd. Forrest DOES NOT VALIDATE the internal format. Nothing that I have said has anything to do with the internal format. If Forrest were to turn on XInclusion during the validation process, this would have no effect whatsoever on internal processing, because what is being validated is the source document. It would, however, remove xi:includes and replace them with what they are referencing, and then validate the result. This is exactly what users expect. > > This means that if a source document XIncludes another source document > > that is available statically on disk/network, as in your use case, then > > the above will work OK. > > > > However, if a source document includes source content that is > > dynamically generated, for example, pulled from a database/RSS Feed/Jira > > instance etc. then we would have to fire up Forrest to generate these > > sources. If we are validating source documents before we fire up Forrest > > we end up in a catch 22. No more so than is already the case. At the beginning of this thread I was trying to use xi:include to include straight text. I got this to work with 'forrest run' by properly declaring xmlns:xi in the document element. But I couldn't get by 'forrest site' without modifying the DTD. Anyone XIncluding dynamic content would already have the same experience: they could only get through validation by either disabling validation for documents using XInclude or by defining a new DTD which includes xi:include elements. The former means that the end document is just not validated, which for some users will be a serious problem. The latter is a pain in the neck and doesn't comply with XML standards. It only works, insofar as it does, because internally Forrest ignores the augmented DTD, the one declaring xi:include elements. > > One solution would be to fire up a running instance of Forrest (aka > > forrest run) and have Xerces validate the xincludes by retrieving them > > from the running instance of Forrest. But this really is clumsy and I > > would guess non-trivial. > > > > My point is, any solution that is created to better support the first > > use case (including static content) must also work in the second use > > case (including dynamic content). > > Let me clarify so as not to discourage your hunt for a solution... > > Any solution would need to work alongside a solution that works for the > dynamically generated content stuff. Personally, I think being able to > turn off validation on certain pages, as is currently the case, is just > fine. A cleaner solution, which involves little work, is to add an include element to document-v20, which has the same attributes as xi:include. Also permit a xmlns:xi attribute on the document. Internally Forrest would replace <include> elements with <xi:include> elements, preserving the attributes. Then turn on XInclusion in the parser. Advise users that if they want to avoid validation of XIncluded XML (because the XML doesn't exist yet, because it isn't static) they should use the <include> element - which could only be used in certain places. If they want validation, they would use the <xi:include> element, which XML allows to be used much more widely. In either case anyone wanting to use XInclude would have to add the xmlns:xi attribute to the document element. -- Jim Dixon [EMAIL PROTECTED] tel +44 117 982 0786 mobile +44 797 373 7881
