OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

ebxml-regrep message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]

Subject: Re: RIM edits: metadata


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.


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

org:Sun Microsystems;Java Software
adr:;;1 Network Dr. MS BUR02-302;Burlington;MA;01803-0902;USA
fn:Farrukh Najmi

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]

Search: Match: Sort by:
Words: | Help

Powered by eList eXpress LLC