Hi Ethan. Thanks for your comments.
On 05/04/09 08:41, Ethan Quach wrote: > > 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 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 Thanks for the links. I've started looking at them, but don't want to comment on them yet as I haven't finished and don't want to delay this email. > > > I think we came to the conclusion that simply adding a version > field in the schema doesn't fully solve our issues. Yes, but if we add a version field to the schema and to manifest, we can see whether the schema and manifest are a good pair. Building on this, if we make a radical change to the schema, we can version the new schema appropriately and ship that schema along with all the old ones (also versioned). We can set up to automatically pick the right schema to use to validate the manifest with. ManifestServ can loop through all schemas, checking their version numbers for a good fit with the manifest, and select the right one. (The schema would have a min version, and ManifestServ would check for the highest min version which doesn't go beyond the version of the manifest.) > 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? If we ship all older schemas and version properly, this shouldn't be an issue. This all makes the assumption that we're not going to be radically changing the schema very often, else we'll have too many schemas to send along. For minor changes we can do optional or choice tags. If we have too many changes or tags, we can just rev the version and "start over". This goes with at least 1-4 of best practices of the www.xfront.com/Versioning.pdf document. I realize this is only one document, and I am looking at the others. Thanks, Jack
