Node Type Registry Limitations and Solutions
 
  Limitations:  
  • It works with only one application (my classes).
  • It supports only one class per type.
    (I may wish to use a variety of customizer or view classes.)
  • Entries have session scope - a bit untidy.
 
  Solutions:  
  • Get class names from a 'stylesheet' (or DCD, XSchema, or whatever).
  • Associate element/class names with namespace, per application?

    • (Eg. application A should use element class X to represent element Y.) 
     
  
Previous     Next
 

 
 Narrative

Limitations

The Node Type Registry is essentially a 'local' solution, and works well in this situation. It is not ideal, however, when processing XML files about which it has no knowledge. We need a 'standard' way of identifying which classes to use when we encounter a new XML file. Someone 'publishing' an XML document needs a way of telling the world which existing classes are most suitable for this new document.

Also, while registering a single class of each type for each entity type/name is perfectly adequate, there will probably be situations in which we will want to choose between a variety of alternatives. We may wish to develop alternative Customizer classes, tailored to different audiences (software engineers versus animated paperclip lovers); different View classes are required if we are to fully exploit the power of stylesheets in WYSIWYG editing.

Any entries added to the node type registry remain in memory for the life of the application. This means that entries loaded for one document (and, indeed, by one document) can affect the behaviour when parsing subsequent documents. While this is probably not a problem in practice, it is conceptually untidy. It would be preferable to introduce a better 'scoping' mechanism; entries loaded for one document could be discarded after parsing that document.

Solutions

Even the 'local' implementation can be improved by replacing a monolithic registry with information from a 'stylesheet'. It will allow swapping between multiple alternative classes.

A 'global' solution, however, requires that the processor of an XML document can obtain information about that document - the namespace mechanism seems the ideal way to do that. The site identified by the namespace's URL could identify all the classes to be used in association with the document, with a different set of classes for each known application product.

Caveat

Even the 'local' implementation can be improved by replacing a monolithic registry with information from a 'stylesheet'. It will allow swapping between multiple alternative classes.