Lists Home |
Date Index |
- From: "Simon St.Laurent" <firstname.lastname@example.org>
- To: Wayne Steele <email@example.com>, firstname.lastname@example.org
- Date: Tue, 08 Aug 2000 17:32:10 -0400
At 01:36 PM 8/8/00 -0700, Wayne Steele wrote:
>This is really hard, and probably impossible to do without reworking DTDs.
For the most part, I don't think it's that difficult. Identifying a
prefix->URI mapping within the DTD would give a parser an opportunity to
use that information against whatever namespaces it encounters in the
document. Assembling multipart DTDs will still be somewhat tricky, but
this seems much simpler to me than stacking parameter entities on each
>I think most people would accept, as a compromise, restricting
>themselves to a one-to-one mapping of prefix to namespace, if they could
>somehow inform the DTD of the proper prefix for each namespace (each
>document gets to make its own mapping). It would be nice to allow a
I'm not sure we'll be able to get to many-to-one in a single step, but maybe.
>The question then becomes: How do you "inform" the DTD of the proper
>prefix for this instance document?
>One solution that's been discussed here is using the internal
>subset of the instance document, to "inform" the DTD through
>redeclaration of certain Entities.
>Careful use of Entity Refs in the DTD just barely allow you to get by with
I'd rather just have a PI in the DTD or even a NOTATION that does the
mapping on the DTD side. It'd require a new generation of processors, but
that might be acceptable for the use cases where this is necessary...
>This Just occured to me: The System Identifier! Since it's a
>URI, it has lots of room for sneaking stuff into it.
>Instead of having a URI like
>you could use
>The web server would have to:
> a. get the ProtoDTD
> b. send it through a ProtoDTD-to-DTD processor, with this param:
> c. return the new DTD to the requestor.
>For offline work, or without a whole web server:
>Instead of using the System Identifier
>I could set up a different URL handler, and use:
>to do the same thing.
>The only downsides I can think of are:
> Someone has to actually write the code to do this (shouldn't be too hard)
> Comparing the System Identifiers of XML documents becomes much more
> It makes the System Identifier really verbose and ugly.
Verbose and ugly is an understatement - I can't see this as workable.
XML Elements of Style / XML: A Primer, 2nd Ed.
http://www.simonstl.com - XML essays and books