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: URI, SOI (off topic)


/ Terry Allen <tallen@sonic.net> was heard to say:
| changing the subject line for variety ...
| | Terry, are you really suggesting that this boils down to
| | 
| |   <uri target="first uri" destination="second uri"/>
| 
| I don't see why it isn't sufficient, but I may be missing
| something.  It has the advantage of being real simple and
| perfectly scaleable to new types of XML function.
| 
| | and that's all we should provide?
| 
| Well, no, we agreed to do something else.  But Paul's good
| points about the XML function/context typology in the socat
| have caused me to wonder whether it's needed.  Strictly,
| this is all off topic and out of scope.

I don't see how this is off-topic at all.

  The objective of the Entity Resolution TC is to provide facilities to
  address issue A of the OASIS catalog specification (TR 9401). These
  facilities will take into account new XML features and delete those
  features of TR 9401 that are only applicable to SGML, as well as those
  features applicable only to issue B in TR 9401.

The "system" and "public" contexts are clearly in TR9401. We might
decide to scrap "notation", "entity", and some of the other TR9401
features that aren't readily accessible in XML parsers (i.e., exposed
by SAX). (Or we might not.)

But I explicitly see "namespace", "schemaloc", "stylesheet", and
possibly "include" as contexts that comprise "new XML features".

| Um, yeah, you want to call things by their exact names, don't
| you?  (Or point at them by their exact locations, or abuse names
| as locators or locators as names ....)

Well, yeah, I probably do, but I don't want to be constrained to an
absolutely global mapping. That would not satisfy the requirement to
provide TR9401 features, IMHO.

If we consider L(public) as the language of public identifiers (i.e,
the set of all strings that are legal public identifiers) and L(system)
as the language of system identifiers, since the intersection
of L(public) and L(system) is not empty, I want the ability to map
foo in a public identifier differently from foo in a system identifier.
Anything else introduces ambiguity not present in TR9401.

I think it's entirely logical to extend this to additional functional
classes.

| You can always make a URL or URN for "the latest version
| of foo", though I don't know that it would be real useful for
| XML.

I use it all the time. The URI
http://nwalsh.com/xsl/docbook/html/docbook.xsl always points to the
most recent version of the DocBook stylesheets.  Since I *don't* have
catalogs (yet!), I can't publish a reasonable URN (I can't *get* a URN
but that's a different issue...) or public identifier so I have to
publish a system identifier and I want it to resolve to something.

                                        Be seeing you,
                                          norm

-- 
Norman.Walsh@East.Sun.COM | All professional men are handicapped by not
XML Technology Center     | being allowed to ignore things which are
Sun Microsystems, Inc.    | useless.--Goethe


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


Powered by eList eXpress LLC