[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [entity-resolution] Mixing XML Catalog and TR9401
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 / "Lauren Wood" <lauren@textuality.com> was heard to say: | 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. Right. As it happens, since they have the same semantics, they can largely be implemented the same way, but that's irrelevant. Daniel's key point is interoperability. Interoperability is a function of conformance to specifications and the normative requirements of specifications. An implementation is conformant if and only if: 1. It does everything the specification says it must. 2. It does nothing the specification says it must not. A specification may provide optional features. Two implementations are interoperable if and only if they are both conformant and they implement the same optional features. Since interoperability is a goal, it's a good idea to limit the number of optional features (ideally zero, I think the XML Rec says). But that's not always practical. XML makes validity checking an optional feature. XSLT makes serialization an optional feature. XML Schema and RELAX NG allow annotations from other namespaces (Kohsuke Kawaguchi's RELAX NG validator allows Schematron statements in RELAX NG and validates them both simultaneously.) In XML Catalogs, we say nothing about the type of catalog identified by a nextCatalog or deletege* URI. We say a lot about exactly what it means if the catalog is an XML Catalog, but we explicitly allow the catalog to be something else. (Perhaps it's fairer to say we implicitly allow it and we should make it more explicit.) This is one of the ways in which XML Catalogs are extensible. I've implemented other extensions. I have a resolver that understands <ext:systemSuffix suffix="docbookx.dtd" uri="/share/doctypes/docbook42/xml/docbookx.dtd"/> Using that resolver, any system identifier that *ends with* docbookx.dtd is mapped to /share/doctypes/docbook42/xml/docbookx.dtd (It may, in fact, be the case that the Apache resolver does this out of the box, but I haven't checked.) Resolvers that use extensions (of either kind, or some other) are not interoperable with resolvers that do not understand them. C'est la vie. | 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. If you wish. | At the very least, that resolution of issue 23 needs to go into the | specification. I couldn't find it in there. Section 8 (Resource Failures) says, in part: Similarly, if the resource retrieved is not an understandable catalog (because it is not in a format that the processor recognizes, or it purports to be XML but is not well-formed, or for any other reason), the processor must recover by responding as if the resource could not be loaded. Be seeing you, norm - -- Norman.Walsh@Sun.COM | Klein bottle for rent; enquire within. XML Standards Architect | Web Tech. and Standards | Sun Microsystems, Inc. | -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: Processed by Mailcrypt 3.5.7 <http://mailcrypt.sourceforge.net/> iD8DBQE+gLR7OyltUcwYWjsRAu/rAJ94CDFugCIlZpwndAQi+cwyD+UcRwCgqLrv bViJYTDXKVJKgXRNitxv6h0= =5T/Z -----END PGP SIGNATURE-----
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]