While working on the XML sequencer, I determined that I will need access (via the SPI project) to some "well-known" namespace URI's in order to build node names, types, and path segments correctly.  There are a few options here:

1. Define the URI's in a separate class or interface, or
• Con: The need for an "artificial" class just to hold constants always feels a little non-OO (although I guess that argument could be made for anything that's considered globally accessible).
• Con: It is not necessarily an intuitive place for developers to look when working with a particular API.
• Pro: This could provide a "default" location to store other constants that we determine we need during the course of development.

2. Define them in an existing class, such as the org.jboss.dna.spi.graph.NamespaceRegistry interface.
• Pro: The constants (or methods) would be defined near the methods with which you would most likely use them, potentially making it easier to know where to look for them.
• Con: There may not always be an appropriate class to define such constants (or methods).
• Con: When the constants are appropriate for use with multiple classes, it may be difficult or somewhat arbitrary deciding in which class they should be defined.
  

where by "define", we could either:

1. Provide constants for the URI's (e.g., public static final String JCR_URI = "http://www.jcp.org/jcr/1.0"), or
• Pro: The value of the URI would be readily apparent within the JavaDocs (via @value).
  
2. Provide methods to return the URI's (e.g., similar to NamespaceRegistry.getDefaultNamespaceUri()).
• Pro: This may provide more consistency with other methods (such as the example above).
• Con: Not sure if a method would be the intuitive place to look for a constant value.

I don't really have a religion regarding this one way or the other.  I just want to establish a pattern up front that everyone is comfortable with, and so I can put as little thought as possible towards this in the future.