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: Proposed URI classes


[This bounced the first time I sent it, because I had a line that
contained the word a-d-d followed by the word t-o followed by the word
l-i-s-t. I've asked the list management folks to relax a little :-)]

--begin forwarded message-

[I never saw this come over the entity-resolution list, but it is
a-d-d-r-e-s-s-e-d to the list, so I'll quote the whole thing here.]

/ John Cowan <cowan@locke.ccil.org> was heard to say:
| On Mon, 20 Nov 2000, Norman Walsh wrote:
| 
| > / John Cowan <jcowan@reutershealth.com> was heard to say:
| > | I think on the contrary that XMLcat should be extensible, so that any
| > | token can be used here, and it is up to a specific Rec (in principle)
| > 
| > Are you unsatisfied by my earlier suggestion of using another
| > namespace for extension? If so, do you have an alternate proposal?
| 
| Okay, yes.  I am proposing a semantic triple (key, source, target),
| where source and target must be URIs and key is a string.
| This says "When source is used as key, remap it to target."

I think that's the basic mechanism that we're talking about, but...

| E.g. key "system" remaps URIs used as system ids, key "include"
| maps URIs used as includes, key "namespace" maps URIs used as
| namespace names.  But beyond these and a few others, it's up
| to the application to look up any URIs it wants to under any key
| it wants to.

Are you suggesting that the content model for <catalog> should
be completely open?

  <catalog>
    <system source="xxx" target="yyy"/>
    <public source="xxx" target="yyy"/>
    <widget source="xxx" target="yyy"/>
  </catalog>

I don't like that at all, I'd prefer:

  <catalog>
    <system source="xxx" target="yyy"/>
    <public source="xxx" target="yyy"/>
    <ext:widget source="xxx" target="yyy" xmlns:ext="zzz"/>
  </catalog>

We could provide a schema type for this element to make declaration
easier.

The problem, as I see it, with leaving the content model completely
open is that you don't get any error detection.

| This is analogous to the DNS, where there are some types that
| have universal meaning, like A, PTR, MX; but there are others
| that can be used for an application for whatever purpose it
| wants.
| 
| > I'm not sure what it should mean if a catalog processor happens
| > across <widget src="xyz" target="abc" xform="def"/> in the catalog...
| 
| Neither do I, unless "widget" == "remap".
| 
| -- 
| John Cowan                                   cowan@ccil.org
| One art/there is/no less/no more/All things/to do/with sparks/galore
| 	--Douglas Hofstadter

                                        Be seeing you,
                                          norm

-- 
Norman Walsh <ndw@nwalsh.com> | It is seldom that any liberty is lost
http://nwalsh.com/            | all at once.--David Hume


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


Powered by eList eXpress LLC