Working multiple versions of a schema with the same name

[Glovit]

We have a schema that has been changed for each product release and we are still having to update the legacy content.

Today, the xml assets for each version have their own path to the to the xsd file called out in xsi:schemaLocation and I have a xac file with the document customizations and rules located at each location. For example, I have v1 of my product at a path of \sharev1foo.xsd and v2 at \sharev2foo.xsd.

How can I deliver local xac files so my users can work on the multiple versions when they are offline and do not have access to my network location?

Should I create a macro that reads the schema location, determines if they can access the network file, and if they cannot, load the appropriate version of the foo.xac from the rules folder? (Rules/v1/foo.xac or Rules/v2/foo.xac)

I am wanting to move way from using the network share as the location for the schemas and distribute the xac file to each client. (having the path in the xml files creates a dependency on the network share location and that has proven a bit painful for maintenance in the past).

Is it possible to force XMetal to use the local xac file rather than the location in my xml files? I'm thinking I'd like to use the path in the schema location as an indicator of the version that is to be used, but to actually use the local xac and not have any files reside on the network share.

Reply

[Glovit]

Forgot version information. Using XMetal Author Essentials 6.0.1.

Reply

[Derek Read]

If you were using a DTD then it would be best practice to create a PUBLIC ID in the XML document that contains version information and then simply provide XMetaL with a catalog file that maps the different PUBLIC ID values to SYSTEM ID (which in this case could be anywhere, including the Rules folder). But you aren't, so…

One way to do this is to move the files to the local machine and then change the schemaLocation to point to them there. You are effectively using the equivalent to a full path right now (that includes a network machine name) so this would translate to:

C:Program FilesXMetaL 6.0AuthorRulesv1foo.xac
C:Program FilesXMetaL 6.0AuthorRulesv2foo.xac

Alternatively, you can provide a scripting solution (if you don't want to or cannot mess with the paths in the XML). To do this I think you would need to create an application-level macro containing the event On_Application_Resolve_Entity

Inside that event use the following read/write properties to check for identifiable information (just throw them up in an Application.Alert first to see what it returns for your particular documents):

Application.Alert("System ID: " + Application.ResolveEntityInfo.systemID);
Application.Alert("Public ID: " + Application.ResolveEntityInfo.publicID);

In the case of an XSD there is technically no “SYSTEM ID”, however, I believe XMetaL will return the value for your schemaLocation in this case. Your logic might be similar to the following:

var currLocation = Application.ResolveEntityInfo.systemID;
...do some check using regular expression or other logic here...
var newLocation = ...modify the value somehow...
Application.ResolveEntityInfo.systemID = newLocation;

Of course, this means that what systemID initially returns has to be different for your v1 and v2 so you can tell them apart (I assume that must be the case).

Reply

[Glovit]

Thanks Derek! This is super helpful and exactly what I am looking to do.

Reply

[Author]

Posts