Date:         Tue, 25 Jan 2005 13:36:44 -0500
Reply-To:     Metadata Object Description Schema List <[log in to unmask]>
Sender:       Metadata Object Description Schema List <[log in to unmask]>
From:         "Ray Denenberg, Library of Congress" <[log in to unmask]>
Subject:      Re: merits of a type library
Comments: To: Metadata Object Description Schema List <[log in to unmask]>
Content-Type: text/plain; charset="iso-8859-1"

> > 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.
>
> OK.

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
be namespaced.)


> > 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.


--Ray