On May 29, 2008, at 10:05 AM, John P. A. Verhaeg wrote:
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:
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.
Pro: There
maybe better handle different families of namespaces (e.g.,
"JCR1", "JCR2", "XSD", "DNA", etc.).
Pro: The pattern is extensible and can be copied by connectors,
sequencers, etc.
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:
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).
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.
Con: Could be changed/overridden by implementations; there seems to
be no benefit to this.
Con: The "NamespaceRegistry.getDefaultNamespace()" method does not
return a constant value - the method returns whatever namespace URI is
at that moment defined to have a zero-length prefix. These well-known
namespace URIs are really constants.
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.
Really, if we're just talking about the "standard" namespaces (e.g.,
"jcr", "nt", "mix") and any DNA namespaces, then really
these have to
be defined by the sequencer's node type definitions. Maybe the
sequencers should just expect the standard namespaces to be registered
already?
Thoughts?
BR, Randall