[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message]

Re: Public Identifiers

  • From: "G. Ken Holman" <gkholman@C...>
  • To: xml-dev@i...
  • Date: Tue, 22 Sep 1998 19:47:19 -0700

doctype rdf
I've hesitated jumping in to the discussion since the SIG went through it
in detail so long ago, but something discussed back then has not been
raised in this forum where there are other participants who didn't see the
earlier discussions.

At 98/09/18 06:49 -0500, W. Eliot Kimber wrote:
>In hindsight, it's clear to me that we never should have allowed public IDs
>in XML.  

Two uses of Public Identifiers that have, I believe, been overlooked
throughout this discussion, and I feel I personally need, are (1)
receiver/user resolution when system id unavailable and (2) copy
identification (e.g. versioning).

(1) Consider I have an XML document on a CD-ROM (or password-protected for
write, or behind a firewall for write permissions, or some other condition
rendering it read-only).  It might be very large, so large I don't want to
copy it to a local environment where I can modifiy it.  I may not even have
permission to make a local copy in which I can modify it.

Now, some external resource refered to in the read-only file is identified
by both a SYSTEM identifier and a PUBLIC identifier:

 <!DOCTYPE pres
   PUBLIC "+//ISBN 1-894049::CSL::Presentations//DTD Presentation//EN"
   SYSTEM "http://www.CraneSoftwrights.com/shareware/presdev/pres.dtd">

The XML Processor discovers it cannot access the URL for whatever reason
(server down, firewall, whatever).

A Public Identifier Resolution Mechanism, if it were available in the XML
Processor, can obtain the necessary local copy if I give it information
about a copy I made some previous time when I did have access to the remote
resource.  And by changing the information to the resolution mechanism, I
can move it around freely without changing the read-only resource.

Without a public identifier, and without the ability to modify the
read-only resource, I would have to resort to some kind of System
Identifier remapping mechanism if it were available in the XML Processor.

I would think it "cleaner" to do public identifer mapping, rather than
system identifier remapping, though I will acknowledge both will end up
with the same results.

(2) In the life of a DTD, I may create a number of instances conforming to
different versions:

One day:

 <!DOCTYPE RDF
   PUBLIC "+//IDN w3.org//DTD RDF Version 1.0//EN"
   SYSTEM "file:///s|/rdf/rdf.dtd">

Three months later:

 <!DOCTYPE RDF
   PUBLIC "+//IDN w3.org//DTD RDF Version 1.1//EN"
   SYSTEM "file:///s|/rdf/rdf.dtd">

Three months after that:

 <!DOCTYPE RDF
   PUBLIC "+//IDN w3.org//DTD RDF Version 2.0//EN"
   SYSTEM "file:///s|/rdf/rdf.dtd">

Each one pointing to the same file that has been updated on the fly.

One feature of an XML Processor might be that if an error is detected
through the use of the resource found through the SYSTEM id, offer to the
user to begin processing again through the resource found through the
PUBLIC id without obliging the user to change the source file.

I'm emphasizing the temporary nature of this feature, perhaps because this
is a one-off run for the user.  For conformance reasons the governing DTD
is the one found through the SYSTEM identifier, so it shouldn't be default
behaviour of a processor to categorically "try again" with the PUBLIC
identifier when there is a fault using the SYSTEM identifier ... but a
courtesy "restart with override" feature might be offered once the
conformance requirement to stop has been met.  

This second issue is fuzzy, but I hope I've conveyed how the following
resolution of the public identifiers would help:

   PUBLIC "+//IDN w3.org//DTD RDF Version 1.0//EN"
          "file:///s|/rdf/rdf-1-0.dtd"
   PUBLIC "+//IDN w3.org//DTD RDF Version 1.1//EN"
          "file:///s|/rdf/rdf-1-1.dtd"

I'm more interested in the utility of the first issue.

To me it makes more sense to map public identifiers than remap system
identifiers.

............. Ken

--
G. Ken Holman               mailto:gkholman@C...
Crane Softwrights Ltd.  http://www.CraneSoftwrights.com/x/
Box 266,                                V: +1(613)489-0999
Kars, Ontario CANADA K0A-2E0            F: +1(613)489-0995
Training:   http://www.CraneSoftwrights.com/x/schedule.htm
Resources: http://www.CraneSoftwrights.com/x/resources.htm
Shareware: http://www.CraneSoftwrights.com/x/shareware.htm


xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@i...
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/
To (un)subscribe, mailto:majordomo@i... the following message;
(un)subscribe xml-dev
To subscribe to the digests, mailto:majordomo@i... the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@i...)


PURCHASE STYLUS STUDIO ONLINE TODAY!

Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced!

Buy Stylus Studio Now

Download The World's Best XML IDE!

Accelerate XML development with our award-winning XML IDE - Download a free trial today!

Don't miss another message! Subscribe to this list today.
Email
First Name
Last Name
Company
Subscribe in XML format
RSS 2.0
Atom 0.3
 

Stylus Studio has published XML-DEV in RSS and ATOM formats, enabling users to easily subcribe to the list from their preferred news reader application.


Stylus Studio Sponsored Links are added links designed to provide related and additional information to the visitors of this website. they were not included by the author in the initial post. To view the content without the Sponsor Links please click here.

Site Map | Privacy Policy | Terms of Use | Trademarks
Free Stylus Studio XML Training:
W3C Member
Stylus Studio® and DataDirect XQuery ™are products from DataDirect Technologies, is a registered trademark of Progress Software Corporation, in the U.S. and other countries. © 2004-2013 All Rights Reserved.