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] | [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]