What I've been playing with on schemas I need to validate, is adding the schema as an arbitrarily named processing instructions like:
<?swie-meta name="schemaLocation" value="http://.....";?> The tag 'swie-meta' is arbitrary and can be selected using XPath with "/processing-instruction('swie-meta')" The only down-side is that there doesn't seem to be a standardized way to access the "pseudo-attributes" within the PI. The might look like attributes but it's API dependent on whether you have any functionality to process them other than string parsing. --Jens On 05/04/09 14:39, Jack Schwartz wrote: > Hi Jens. > > On 05/01/09 20:01, Jens Deppe wrote: >> Hi Jack, >> >> You might also consider putting the schema into a processing >> instruction statement. That way you could still have it easily >> extracted by other XML tooling such as XPath. > Thanks for your suggestion. If you mean add the version to the schema > and then read the schema as an ordinary XML file, I tried that but ran > into a problem. I tried adding a version to the schema header first, > and then to the schema itself. I could extract that information just > fine when I read the schema as an ordinary XML file, but the validator > (xmllint) complained when I used the schema to validate the manifest. > > Thanks, > Jack >> >> --Jens >> >> 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? >>> >>> Thanks, >>> Jack >>> >>> >>> ------------------------------------------------------------------------ >>> >>> _______________________________________________ >>> caiman-discuss mailing list >>> caiman-discuss at opensolaris.org >>> http://mail.opensolaris.org/mailman/listinfo/caiman-discuss >
