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

 


Help: OASIS Mailing Lists Help | MarkMail Help

entity-resolution message

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


Subject: Re: XML Catalog issue 3


At 14:33 2001 03 19 -0500, John Cowan wrote:
># What do we do about delegate? Do we need to have a delegate for
># public identifiers, a delegate for system identifiers, etc.
># This is the functional class versus syntax issue again. URNs where?
>
>Well, delegation for public ids is essential, both because no one else
>can do it, and because 9401 had it. ... Therefore I support adding it.
>
>For syntax, I propose adding attributes to the delegate element.
>The obvious choices are systemIdStartString and URIStartString.
>
>However, RDF already has the concept of a URIStartString, called
>a "prefix".  So I support changing "publicIDStartString" to
>"publicPrefix" and adding "systemPrefix" and "URIPrefix".

I'm a bit concerned about having to make clear just how to handle
cases where a single delgate entry has, say, assignments to all
of publicPrefix, systemPrefix and URIPrefix (or whatever they are
called).  Though I'm sure we could define things so that the attribute
form is logically equivalent to the separate entry type form, I'd like
to hear what is wrong with having different entry types such as:

  delegate-publc or just delegate for public ids
  delegate-system for system ids
  delegate-URI for other URIs.

Given that we have separate entry types for public, system, and URIs,
I think this would end up being easier to explain and easier for users.

paul



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


Powered by eList eXpress LLC