Jack Schwartz wrote: > Hi Ethan. > > I think I figured out a way to do RelaxNG schema versioning. > > Where we had left it when we talked earlier, the document you pointed > me to (www.xfront.com/Versioning.pdf) had good ideas, but without a > schema versioning mechanism, they were hard to implement. > > RelaxNG schemas don't allow versioning in their headers, but we can > put the schema version in a comment in a RelaxNG schema to workaround > this. We can then have the parser validate the manifest against it > before using the manifest. > > The thing missing by putting the version in the comment instead of the > header (as in a DTD) is that there is no mechanism for the parser > proper to check it. No problem though... ManifestServ can add a check > of its own to look for the special comment in the schema (a grep > through the file, perhaps) to extract the version number. Next, it > would pre-parse the manifest to get the version of the manifest and do > the compare. If the check passes, preprocessing ensues and the data > is prepared for consumption by AI. > > As long as the schema version is in the schema somewhere, and the > parser knows how to find and check it, its robustness is the same. It > doesn't matter whether it is in a comment or in a header. > > Do you see any holes or omissions here, or does this make sense? > Other thoughts?
We also discussed revisiting the schema itself so that its not too rigid wrt the installer per-build. Have you given this any thought yet? Here are a couple links to look at with some general concepts on schema design http://www.xml.com/pub/a/2004/07/21/design.html http://osteele.com/archives/2004/08/xml-schema-versions I think we came to the conclusion that simply adding a version field in the schema doesn't fully solve our issues. We don't want users' instance documents to be stuck per-build. In our current approach, the only way to add new features or to change features without breaking older instance documents is to make modifications wrapped around optional or choice tags. This may be viable one or two times, but going forward, is this tenable? thanks, -ethan > > Thanks, > Jack
