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

["Lauren Wood" <lauren@textuality.com>]

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

  There is also implementation details which makes it a annoying in
the case of libxml2, but well, it's implementation not a fundamental
issue, just an annoyance.

  A separate issue I would like to point out, is that in the Linux 
framework I tried to get XML default catalogs to get located in 
/etc/xml/catalog , the reason is that one cannot expect all users to
reliably have an environment variable or another mechanism to 
indicate
to the XML tools where to lookup catalogs by default. Having a 
predefined
path is useful to get some default system wide processing. 
Traditionnally
the SGML tools have used "SGML_CATALOG_FILES" environment variable, 
for
libxml2 I used "XML_CATALOG_FILES" as the environemnt variable 
allowing
to override the default /etc/xml/catalog,  maybe your group could
suggest where to find the system catalog entries, this would 
definitely help
on interoperability, I understand that /etc/xml/catalog is very Linux
specific (won't work on Windows and I think Sun changed that when 
embedding
libxml2) still at least suggesting an environment variable would be 
nice.

> At the very least, that resolution of issue 23 needs to go into the 
> specification. I couldn't find it in there.

 Thanks for considering the issues, and sorry for not posting to the 
proper list address initially,

  yours,

Daniel

-- 
Daniel Veillard      | Red Hat Network https://rhn.redhat.com/
veillard@redhat.com  | libxml GNOME XML XSLT toolkit  
http://xmlsoft.org/
http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/
------- End of forwarded message -------