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)

Norm wrote:
| I don't see how this is off-topic at all.

Well, I agreed it was.

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

BTW, I think that style sheets are not comparable to system,
public, and entity.  They're certainly not needed for parsing the
instance.  Schemaloc is a parallelism for the doctype decl; I'll
pass on "namespace"; but why do we need to call out the function
of style sheets in the catalogue? 

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

What lies in the intersection is URLs and URNs, I think.  Okay,
why do you feel the need for the ability to map a URL (or URN)
in a system ID differently from the same URL (or URN) in a 
public ID?  I'm still looking for an example.

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

But you wouldn't want to do that with DTDs, and the most recent
version of the Docbook ssh is for the most recent version of Docbook.
So over major revisions, this URL may well cause breakage.  Not that
you can't make good use of it over shorter time spans.

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

Well you do have socats, but you can also use a URN as a system ID
and map system to system.

SYSTEM "-//OASIS//DTD DocBook XML V4.1.1//EN" "../xml/norm/411/docbookx.dtd"

which is what I do on my own machine; and it would work over the
net if I used 

SYSTEM "-//OASIS//DTD DocBook XML V4.1.1//EN" 

at least I think it would.  Forget about PUBLIC; it got broken.

regards, Terry

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

Powered by eList eXpress LLC