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

Re: URNs as SYSTEM IDs

  • From: "Simon St.Laurent" <simonstl@s...>
  • To: michaelm@n...
  • Date: Mon, 27 Nov 2000 10:55:19 -0500

w3c canonical url
At 08:17 AM 11/27/00 -0500, Michael Mealling wrote:
>This really isn't intended to be the general case. It came up because
>I was writing a standard that had a DTD in it. XML won't let you
>use a PUBLIC id without a SYSTEM id so I was stuck with three options
>for what to put in the standards document:
>
>1) use "file:/dev/null"

Unusual, and prohibits processing of your documents by validating XML
parsers which don't have entity resolvers set up (by far the majority at
present, in my experience).  It also sends a strange message to developers,
since /dev/null has acquired semantics...

>2) use a real URL and watch that poor server get the hell banged out of
>   it because everyone was downloading the DTD because they were to lazy
>   to use an entity resolver

This is the approach the W3C takes with XHTML.  I'd suggest this makes more
sense than the alternatives, since the PUBLIC identifier allows processors
which support entity resolution to use it (as Mozilla does with XHTML) but
provides a canonical URL which developers who've never heard of entity
resolvers (lots of them) can still use.

The proposal [1] states in Section 1, para 1:
>It is standard practice within W3C
>standards to forego the use of the PUBLIC identifier in favor of
>'well known' SYSTEM identifiers.

I don't think this statement is true, at least for W3C standards which
reference DTDs.  For Schemas, there's an open and rather ugly question.
Even the DTD for Schemas, though, includes these comments:
<!-- DTD for XML Schemas: Part 1: Structures
              Public Identifier: "-//W3C//DTD XMLSCHEMA 200010//EN"
              Official Location: http://www.w3.org/2000/10/XMLSchema.dtd -->

>3) use soemthing that wasn't resolvable but had more name like qualities that
>   would force the implementor to use an entity resolver...

I'm not sure forcing the implementor to use an entity resolver by feeding
them 'bad' URLs is going to make developers happy.

>What should I have done? This will come up often and we (the IETF) needs
>to right solution. I can easily remove any mention of DTDs and URNs
>if needed....

For namespaces, I think the proposal's solution does an excellent job.  For
DTDs and schemas, resolvability really matters.  I'd stick to the
combination of a public identifier and a 'guaranteed' URI (number 2 above),
 but make clear that the public identifier is the critical piece and the
SystemLiteral is only provided for backup.

Among other things, that would let people without entity resolvers point to
local URLs while still identifying the document with the right PUBLIC
identifier.  Should reduce the hell-banging.

[1] -
http://www.ietf.org/internet-drafts/draft-mealling-iana-xmlns-registry-00.txt


Simon St.Laurent
XML Elements of Style / XML: A Primer, 2nd Ed.
XHTML: Migrating Toward XML
http://www.simonstl.com - XML essays and books

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.