Adding printer-specific features to PrintTicket

I've been getting a number of questions lately around guidelines for how to extend Vista / Metro PrintTickets with device-specific features & options.  Hopefully this Q&A will be helpful:

Q: How do I define device-specific features & options?


A: You should use the feature / option structure as defined in the print schema framework. Prefix the features using an appropriate company, product-line, or device specific namespace. For example:


<psf:PrintTicket ... xmlns:MyStuff="">

  <psf:Feature name="MyStuff:MyFeature">






In the example above, the feature name is MyFeature.  The scope of the feature is  The association is created by the 'MyStuff' prefix.  For those of you who might be new to XML, it's important to keep in mind that the namespace prefix only has meaning within the scope of the xmlns declaration.  'MyStuff' could just as well have been 'ns000' or 'foo'.  It has no effect on the semantics of the document.


As far as names of features & options go, it's entirely up to your organization, with the exception that features names need to start with one of three standard prefixes: Job, Document, or Page.


Q: Where else can I use private namespaces for my custom content?


A: For the most part, you can define content anyplace where content in the PrintSchema keyword namespace appears.  The most common extension points would be features names, options names, scored property names, property names & parameter names.


Q: Can I use more than one private namespace?


You can use as many private namespaces as you want, but we recommend that you use your company name in the URI to avoid collisions with namespaces from other vendors.  If you have two features named 'X', and they are associated with different namespace URIs, they will be treated as completely distinct features.  As a practical matter, that means that if you have a family of printers with identical or equivalent features, e.g. a product line, you may want to share private features accross the product line.  This makes it easier for app vendors or even your own internal tools groups to use PrintTicket to control settings for all of the printers in that family.


Q: How should I construct my namespaces?


First, you should see if your company has guidelines for naming public-facing URIs, which may provide recommendations for letter case, naming conventions, versioning, etc.  The most important thing is to design your private namespaces as a system.  Think about how definitions may or may not be meaningful accross devices, and how you can build re-usable definitions that will meet your needs going forward.  Think about creating conventions that will apply accross the models & product lines that you have to support, as well as conventions that will aid you in versioning.  By doing so, you'll make it easier for applications to leverage your device-specific features, and make it easier to scale you implementations accross your entire company.


In a complete ticket I might use multiple namespaces for the same device.  For instance: <- Namespace for features unique to this series <- namespace for features unique to this model <- Namespace for features specific to your company.


As you name features & options, in general you should try to put the names in the most generic namespace that's reasonable for that feature.