[entity-resolution] [David Brownell <david-b@pacbell.net>][entity-resolution-comment] Fw: Comments on OASIS XML Catalogs (2001-08-06)

[Norman Walsh <ndw@nwalsh.com>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Before we declare victory, I think we should take a look at these
comments. Almost a year old, I found them in my comments-archive.
Don't know how we all missed them...

--- Begin Message ---

• From: David Brownell <david-b@pacbell.net>
• To: entity-resolution-comment@lists.oasis-open.org
• Date: Fri, 23 Nov 2001 18:52:32 -0800

Hmm, list only open to subscribers, eh?

- ----- Original Message ----- 
From: "David Brownell" <david-b@pacbell.net>
To: <entity-resolution-comment@lists.oasis-open.org>
Sent: Friday, November 23, 2001 5:55 PM
Subject: Comments on OASIS XML Catalogs (2001-08-06)


> Hi,
> 
> I've recently spent a bit of time implementing this spec, and thought
> I'd share a few comments.  In no particular order:
> 
> - While I'm very glad to finally see a "backed" XML catalog syntax
>   (how many years overdue? :),  I wish the processing model were
>   much more straightforward.  IMO the complexity here is a clear
>   obstacle to its broader adoption: makes it harder to understand
>   and explain, as well as making it more error-prone in use.
> 
> - I really don't see any need to have both the "uri" and "systemId"
>   sets of elements.  They're functional duplicates, except for the
>   fact that "system" elements "should" not have fragment IDs.  It's
>   confusing and error prone to duplicate data like that ... and this
>   spec doesn't even suggest a motivation for such duplication.
>   Why should I need to mention an entity in two places, just because
>   I happen to mention it both in a DTD and elsewhere?  The natural
>   expectation is that only one mapping entry should be needed.
> 
>   One of them should be deleted.  My preference:  keep the "uri"
>   set, since that one has a name that clearly matches its intended role.
>   (Then replace current refs to the "systemId" elements, etc, and
>   simplify section 7.2 as described later in this note.)  It'd be easy
>   enough for implementations to just maintain one set of internal tables,
>   supporting "old" elements for backward-compat (if desired).
> 
>   Yes, I realize an implicit goal was continuity with SOCAT, but
>   this is a case where minor surgery to terminology seems likely
>   to be a long term win ... and I don't recall SOCAT having "uri"
>   mappings anyway.  If SOCAT-friendliness were a primary goal,
>   it'd be rather important to have mentioned one that up front.
> 
> - In 4.1.1, it's messy to support the "prefer" attribute on
>   groups ... catalogs need to maintain multiple distinct tables
>   of public ID mappings and delegations, and figure out when
>   to use each set.  Is that complexity really necessary?  It doesn't
>   seem likely to be very beneficial, and I get concerned about
>   how I'll know if I'm interpreting the spec correctly.
> 
> - The text in 4.1 (and 4.1.1) is needlessly convoluted.  It should
>   be simplified in at least two ways.  First, except for a summary
>   of the intent, all details should be incorporated into 7.1 ... since
>   it took far too many re-readings for me to come up with an
>   interpretation that wasn't self-contradictory.  Second, that
>   summary of intent should become clear!  I think something
>   along these lines is the true result of the spec (with a ref to
>   section 7.1 for detailed semantics):
> 
>     * In "prefer public identifier" mode, all applicable catalog
>       entries are used.
> 
>     * In "prefer system identifer" mode, catalog entries for
>       entity public identifiers are ignored except in the case of
>       system identifiers (URIs) using the "urn:publicid:"; scheme,
>       where public id mapping entries will always be used.
> 
>     * Applications specify a default mode, and catalog
>       entries for public identifier mappings may override
>       that default by using "prefer" attributes on catalog and
>       group elements.
> 
>   In conjunction with updates to 7.1, most of section 4.1.1
>   can/should vanish -- and maybe even the section heading.
>   That's without loss of functionality, and with improvement
>   in clarity.
> 
> - In 7.1.1 the inputs are incomplete:  there's also the application's
>   preferred resolution mode, as confusingly explained in 4.1 ...
>   that needs updating.  The text in 7.1.2 should explain how
>   that input interacts with the "prefer" attributes that may be
>   placed on catalog/group elements.
> 
> - For that matter, this is catalogs for *XML* ... so the lines
>   in 7.1.2 reading "if a system ID is provided..." are dubious.
> 
>   Naturally one was provided!  The _only_ way one won't
>   be in use is if "urn:publicid: mapping in 7.1.1 morphed
>   that system ID into a public ID.  This relates to the rather
>   confusing explaination of the two "prefer" modes; I'd
>   expect they'd all be clarified together.
> 
> - I think 7.2 would be a lot clearer if it could just be
>   explained as:  "just as defined in 7.1, with the input
>   mode 'prefer=system', no public ID, and sysID=uri".
>   Short, sweet, clear, uncomplicated ... :)
> 
> - What should be done for <uri>, <rewriteURI>,
>   or <delegateURI> elements where the matched
>   system ID uses the "urn:publicid:"; scheme?  According
>   to 7.1 and 7.2 any input system ID using such a scheme
>   will be turned into a public ID based match.  For now,
>   I'm issuing a warning and ignoring the entry, since such
>   elements could never match anything.  (Ditto for the
>   duplicative <systemId*> elements ...)
> 
> As for the <?oasis-xml-catalog ...?> PI, I think it'd be
> good if _you_ defined a feature flag URI that parsers can
> use to control this mode.  That could apply to multiple
> parsers (SAX2, JAXP/DOM, JAXP/SAX2, Perl, etc)
> It'd be most appropriate for you to define the URI (and
> control its evolution), and the "define a URI" approach
> (now generally adopted :) was intended to support third
> parties doing just that.
> 
> May I suggest using this URI for the feature flag:
> 
>   http://www.oasis-open.org/committees/entity/use-catalog
> 
> That's it for the moment.  I'll send a note later including
> a URL for the implementation.  (Free Software, in Java.)
> 
> Oh -- not quite all.  What's the story on conformance
> testing for these catalogs -- are there any tests available?
> 
> - Dave
> 
> p.s. I notice that there's no public archive of this
>     "comments" list ... at least, not listed on the page
>     of archived lists!  Worth fixing.

--- End Message ---

                                        Be seeing you,
                                          norm

- -- 
Norman.Walsh@Sun.COM    | Linux. Because rebooting is for hardware
XML Standards Architect | upgrades.
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/>

iD8DBQE9ubo9OyltUcwYWjsRAi9MAKCxk3cE3s/LsAq5xbAHutHN9i4O7ACeOFoT
VRYKHzARHbFBC8oPo7T+Ja0=
=lhph
-----END PGP SIGNATURE-----