Re: [entity-resolution] (Fwd) Re: [entity-resolution] Mixing XML Catalog and TR9401

[Paul Grosso <pgrosso@arbortext.com>]

At 16:08 2003 03 24 -0800, Lauren Wood wrote:
>Assuming that Daniel can't post to the ER mailing list, I'm 
>forwarding this.
>
>Lauren
>
>------- Forwarded message follows -------
>Date sent:              Mon, 24 Mar 2003 18:45:33 -0500
>From:                   Daniel Veillard <veillard@redhat.com>
>To:                     Lauren Wood <lauren@textuality.com>
>Copies to:              entity-resolution@lists.oasis-open.org
>Subject:                Re: [entity-resolution] Mixing XML Catalog and 
>TR9401
>Send reply to:          veillard@redhat.com
>
>On Mon, Mar 24, 2003 at 01:22:25PM -0800, Lauren Wood wrote:
>> I think there are two issues floating around here, and I would like 
>> to try to separate them.
>> 
>> Point 1 is that XML Catalogs should have the same semantics, where 
>> applicable, as TR 9401. This does not mean, to me, that they 
>> necessarily be implemented the same way. As long as implementations 
>> fulfill the specification, that's all that matters. 
>
>  Okay, this is sensible, nothing to argue about :-)
>
>> Point 2: in private email with Daniel, it appears that someone dug up 
>> the issues list (Still, and hopefully for a while, at 
>> http://www.oasis-open.org/committees/entity/issues.html; I have also 
>> linked to it from our group page). 
>> " Should we assert that delegate and nextCatalog entries must point 
>> to other instances of XML Catalogs? Is it an error for delegate and 
>> nextCatalog to point to resources that are not XML Catalogs?
>> 
>> Resolved: 07 May 2001: No. If an application retrieves a catalog that 
>> it does not understand, it should behave as if it was unable to find 
>> the resource. And recover as per issue 15."
>> 
>> Someone is now expecting Daniel to implement a <nextCatalog> to point 
>> to a TR 9401 catalog, which I don't think we ever expected or 
>> discussed. My (I believe shared) expectation was that people would 
>> translate TR 9401 catalogs to XML Catalogs and not seek to interleave 
>> them.

Not necessarily.  When we discussed this, I know Norm and I planned
that our implementations (which already handle TR9401 catalogs) would
accept either kind of catalog.  However, that is admittedly not something
required by any given XML Catalog implementation.  Which is just what
I think our wording says:  if an app cannot understand a catalog, it's
as if there was no such resource. 

>> I therefore propose that we discuss this issue explicitly.
>
>  The fundamental problem is really an interoperability problem,
>and at 2 levels:
>    - for the XML Catalog implementations, if Sun's and Apache's 
>      implementations allow an XML Catalog to point to a TR 9401
>      subtree well, other implementations will have to do the same
>      or face requests from users like I did.

Wait a minute.  You're saying that if someone builds a Mercedes,
all VW manufacturers have to build cars that drive like Mercedes.

I don't want the XML Catalog spec to forbid someone from writing
an implementation that supports both TR9401 and XML Catalogs.  As
Norm has pointed out, there is a lot of shared code, so it makes
a lot of sense to do this.  However, the spec doesn't require it,
and there is nothing wrong with you just implementing XML Catalogs.

As an implementor, you just have to get used to users wanting
Mercedes for the price of a VW--they always will, but they'll
just have to learn they can't always get what they want.  That's
not a good reason to write specs that make it illegal to build
a Mercedes.

[By the way, please don't take the analogy too far--I'm not 
saying libxml is a VW!!!]

>    - for XML deployement, building XML catalogs is one good way
>      to ensure that no SGML resource is referenced by mistake,
>      we had this problem (in Red Hat 7.2 if I remember correctly)
>      of pointing to the ISO SGML resources for XML tools and that
>      was of course a disaster, separating cleanly the catalogs (and
>      the tree of resources) is something which can help prevents
>      those mistakes.

This is another issue, and I don't think we should confuse it
with what XML Catalogs allows implementors to do.

Besides, I have lots of clients referencing SGML and XML successfully,
so I don't think I'd accept this as a good argument.

paul