Re: RIM edits: metadata

[Farrukh Najmi <Farrukh.Najmi@east.sun.com>]

IMHO, the long term solution to this problem is to support user defined Code Classes.
Instances of code classes serve as domain for defining enumeration of codes for that
code class. In this scenario, there would be a ObjectType code class extensible
instances of which would be the enumerations for objectType.

I propose that we consider this issue in phase 2 as IMHO the ROI on it is low right
now. Thanks for your thoughts in advance.

Farrukh Najmi wrote:

> Joe,
>
> You raise an excellent issue.
>
> I have vexed over this issue quite a bit and dont have any good answers yet. My
> current thinking is as follows.
>
> The only use case we have seen for this attribute so far is for  the ability to
> filter on objectType when searching for content in browse and drill down (and later
> ad hoc) queries. There may be other use cases as well. Making the object type a
> user defined string sacrifices consistency among registries and tools such as a
> Registry Browser can no longer show the objectType selection GUI as a set of
> selectable buttons.
>
> So we resigned to pre-defined types with support for type of UNKNOWN to handle
> other cases not pre-defined. I am open to suggestions on how to improve on this
> problem. In the absence of a better solution I am assuming that content must be
> typed by pre-defined types (including unknown) and that new types are added with
> new versions of the registry. Compatibility between regsitries with different
> versions is a broader issue (and a good one) but in this topic I could imagine
> mapping a new objectType from a newer version registry to UNKNOWN in an older
> version registry.
>
> --
> Regards,
> Farrukh
>
> Joseph Baran wrote:
>
> > Jon Bosak wrote:
> >
> > <<snip>>>
> > > ExtrinsicObjects catalogue submitted content whose type is not
> > > intrinsically known to the registry and therefore must be
> > > described by means of additional attributes (e.g., mime type).
> > > Examples of content catalogued by ExtrinsicObject include party
> > > profiles, business process descriptions, and schemas.
> > >
> > > ##################################################################
> > >
> > > ITEM: table beginning at line 411
> >
> > (pre-defined types of ExtrinsicObjects)
> >
> > <<<snip>>>
> > >
> > > static int OBJECT_TYPE_XML_SCHEMA
> > >
> > > An ExtrinsicObject of this type catalogues an XML schema (DTD, XML
> > > Schema, RELAX grammar, etc.).  [just a single type for all?]
> > <<<snip>>>
> >
> > >>>>  [just a single type for all?]
> >
> > This innocent little note raises some other questions (perhaps a
> > meta-question?):
> >
> > Whether or not the various XML schema types should get separate type codes,
> > it seems (IMO) likely that there will be a need to add to the list of
> > "pre-defined types of ExtrinsicObjects" over time.
> >
> > The technology-dependent nature of the items in this list makes it seem to
> > me to be potentially more likely to grow than, for example, the list of
> > types of AuditableEvent would be.
> >
> > So the questions are:
> >
> > 1.      Should the list of pre-defined types of ExtrinsicObjects be extensible?
> > 2.      If so, how does this happen? (i.e., only by a new version of the RegRep
> > spec, or in some other, presumably more "lightweight" way)
> > 3.      If the list can grow, how do we handle the interoperability issues -
> > e.g., what happens if I try to add a new ExtrinsicObject with a "new" type
> > to a registry that doesn't know about the "new" type yet?
> >
> > Note that if the list is extended by anything "less than" a new version of
> > the spec, it implies that there is a "master list" somewhere outside of the
> > spec (similar to the list of registered MIME types).
> >
> > This would seem to open up a few cans of worms...
> >
> > ...Hey, I said I had  _questions_, not  _answers_!   ;-)
> >
> > Joe Baran

--
Regards,
Farrukh

begin:vcard 
n:Najmi;Farrukh
tel;work:781-442-0703
x-mozilla-html:FALSE
url:www.sun.com
org:Sun Microsystems;Java Software
adr:;;1 Network Dr. MS BUR02-302;Burlington;MA;01803-0902;USA
version:2.1
email;internet:najmi@east.sun.com
fn:Farrukh Najmi
end:vcard