Expanded Name vs Prefix Name + Compound DTD: Whats the difficulty?

[Mark Tucker]

Mr Bray gives us an algorithm for using DTD's and Namespaces.  

He suggests "fully prefixing" all the elements with unique
prefixes during a rewriting pass.  

I had the suggestion "In your symbol table, handle XML Element and
Attribute names using the combination of the URI and the local name,
instead of just local name."

>From my point of view, Bray's "Full prefixing" technique
is fine.

mct>*****************************************
mct>	Camp 2 : Tim Bray, Andrew Layman
mct>*****************************************
mct>		To validate a document that uses namespaces, do  all
mct>		the ELEMENT and ATTRIBUTE handling using the Expanded
mct>		Names.
mct>	This group thinks namespaces coexist with DTD's, provided
mct>	both the DTD and the document instance specify consistent
mct>	URI's for the namespaces. The actual prefix abbreviations
mct>	used in the DTD or the document instance don't matter.
tb> Not quite right.  The prefixes are stand-ins for the URIs.  However,
tb> the prefixes are all the DTD processor can see.  Thus, validating 
tb> namespaced documents *has* to be a 3-step process.
tb> 
tb> 1. Build a compound DTD that has prefixed declarations for all your
tb>    elements and attributes.  This is the hard part.

{See Below)

tb> 2. Go through the instance and rewrite all the namespace declarations onto
tb>    the root element and undo any defaulting, so that anything that's in
tb>    a namespace has a prefix.  If necessary, rewrite the DTD so that the
tb>    same URIs have the same prefixes in DTD and instance.  This is tedious
tb>    but straightforward, there are dozens of programmers in this group
tb>    who could sort it out in a day, given a decent XML processor.

Presumably, during this re-writing, we could give the prefixes new
names PF1,PF2,... without effecting the result.  The particular
prefixes chosen do not effect semantics.


tb> 3. Validate (or not, if the doc is broken).
tb> 

tb> What really bothers me is that discussion here keeps obsessing over
tb> the tedious but straightforward problem of matching up prefixes, and
tb> nobody's thinking about the interesting and difficult problem of
tb> compounding DTDs.

I must confess that I don't understand the problem, but it doesn't
look hard.  To the naive eye, I would just read in the relevant DTD's,
and perform the same "Fully Prefixing" operation.  Since the DTD's
would all be prefixed consistenly, can't we just toss all the
productions into the pot, and turn the crank?  How do they interact,
if they all have differently named elements and interactions?



Hot off the press we have...........

Peter Jones wrote:

pj> What do you mean by compounding DTDs? I don't know whether any of my
pj> postings to the list have been getting through, ...but why can't the
pj> notion of a DTD be an utterly nebulous concept in the abstract, elements
pj> themselves having a namespace URIs which addresses a DTD entity for that
pj> particular element. Different elements validated against different
pj> declarations lying in dispersed DTD entities.
pj> Why isn't this idea getting through to anyone? (am v. frustrated!)


I think I agree with you.  I'd just as soon see a DTD as a pile of
ELEMENT and ATTRLIST definitions.

John Cowan replied:

jc> This may be feasible for some yet-to-be-standardized schema language,
jc> but not for DTDs as such.  "DTD" is a fixed, narrow, SGML-compatible
jc> notion that can't be changed.
jc> 
jc> In addition, the namespace draft has laid down that the URI is
jc> used solely for comparison, and needn't represent an existent
jc> resource, much less a specific schema.


Ah, the fact that the URI doesn't represent an existant resource
doesn't matter here!  You can't use the URI to retrieve the DTD,
but, suppose you already know the DTD which corresponds to the URI?
If you magically know the DTD, then you go ahead an apply
and validate the DTD (after either using Tim's re-prefixing, or by
using my symbol table handling mechanism.)

The URI is used only as a unique string that uniquely identifies
a "Resource" (in the RDF sense of abstract thing.)


-- 
==============================================================
Mark Tucker			tucker_m at regenstrief.iupui.edu
Regenstrief Institute		phone: (317) 630-2606
1001 W. 10'th St; Indianapolis, IN; 46202-2859;	fax: (317) 630-6962

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