> > This approach, single namespace, would mean that a single
> > schema would define both root elements, <mods> and <mads> (and whatever
> > other root elements) and then could *include* (rather than *import*)
> > xml for
> > both mods and mads. I believe this would avoid the need for prefixes.
I need to back up a moment before addressing the point below (flexibility).
If (hypothetically) mods and mads <name> were defined identically (not the
case) then the above is true, that is a mods instance or a mads instance
could include the element <name> using the default namespace (no prefix).
But they're not the same, so in the single-namespace approach you need
different names for 'name' e.g. <modsName> and <madsName>. Not much easier
than <mods:name> and <mads:name>.
In fact with separate namespaces it's even easier than that -- in a mods
instance, or in a mads instance, you use just <name>, no prefix -- the
default namespace. ( In an instance of a third schema referencing one or
the other than it would use the appropriate prefix.) So at least for this
example separate namespaces seems to be a simplifying rather than
complicating factor. (Yes it's a bit more complicated because we're talking
about factoring out the common part to the type library and that part would
> > I do think however, from a "big picture" perspective, it would
> > significantly inhibit flexibility.
> What kind of flexibility, for whom?
Well, from the example above, flexibility to define names without fear of
collision. For whom: those defining names and those creating complex
instances that reference them.
We should ask, do we envision that mods and mads are two of a larger family
of schemas, or are we looking for a solution just for these two schemas? In
the latter case a single namespace might be manageable (but still the
example above applies). If we're looking at additional schemas in this
family then a single namespace doesn't seem to scale. And if we employ
multiple namespaces then the type library would be a simplifying factor.