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: Catalog requirements


/ John Cowan <jcowan@reutershealth.com> was heard to say:
| Norman Walsh wrote:
| 
| > In catalog parlance this is the SYSTEM keyword. You don't want to
| > support SYSTEM? I do, I want
| > 
| >   <!DOCTYPE book
| >     SYSTEM "http://www.oasis-open.org/docbook/xml/4.1.2/docbookx.dtd">
| > 
| > to resolve to /share/doctypes/docbook/xml/docbookx.dtd on my system.
| 
| And what I want, by *not* supporting SYSTEM, is to force people who publish
| DTDs to assign them public identifiers.  Which involves fixing the
| FPI infrastructure.   Which is what I really care about.

That's very noble, and I offer my wholehearted support. But I also
think we need to be practical.

| In addition, there is a technical difficulty with SYSTEM vs. base URIs:
| what is the base URI of a document fetched through a catalog redirection?
| If it is the resultant URI (which is what happens with HTTP redirection),
| then any parts of the document addressed with relative URIs must be mapped
| as well, with resulting mess.

It's not a mess, it's exactly what any sensible person expects ;-).

You copy all of DocBook to /your/favorite/place,
You map "http://www.oasis-open.org/docbook/xml/4.1.2/docbookx.dtd" to
   /your/favorite/place/docbookx.dtd
Subsequent requests for "dbnotn.mod", for example, in docbookx.dtd get
   resolved to /your/favorite/place/ because that's the base URI

| If it is the original URI, there are equal
| and opposite problems.

Yep. I see that.

| BTW, in Socats which is done first, SYSTEM mapping or PUBLIC mapping?
| I had thought that SYSTEM mapping could be applied to the output of
| PUBLIC mapping, but I am very likely confused....

No, you can never chain them. Whether or not system comes first depends
on the setting of OVERRIDE.

| > Consider this instance:
| > 
| >   <?xml version='1.0'?>
| >   <doc xmlns="http://example.com/xmlns/namespace">
| >     <para/>
| >   </doc>
| > 
| > If I hand that to a processor, it might want to validate the document.
| > In order to do that, it's going to have to know what schema is
| > associated with that namespace. Shouldn't we provide some mechanism
| > for addressing this problem?
| 
| So this is a sort of client-side CONNEG?

CONNEG?

| > The real problem, alas, is that Namespaces[1] says you can't do
| > anything with that namespace name except literal comparison.
| 
| Not exactly, just that Namespaces as such doesn't prescribe anything.
| RDF Schemas, for example, prescribes that you put an RDF Schema there.

Hmph.

                                        Be seeing you,
                                          norm

-- 
Norman.Walsh@East.Sun.COM | 'I have done that,' says my memory. 'I
XML Technology Center     | cannot have done that'--says my pride, and
Sun Microsystems, Inc.    | remains adamant. At last--memory
                          | yields.--Nietzsche


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


Powered by eList eXpress LLC