Lists Home |
Date Index |
"J.Pietschmann" <firstname.lastname@example.org> wrote:
| Arjun Ray wrote:
|> I sense a prejudice that processing DTDs is inherently "difficult"
|> (and thus something it might be useful to, um, "optimize away".)
| Whether it is difficult or not, it takes processing time and other
I'd love to hear about that magical formalism for declarative information
which doesn't take processing time and resources.
(This sounds like the same prejudice: "Things I like really don't take
time and resources, and things I don't like obviously do." Manufacturing
technical reasons for visceral distaste is humbug.)
| in particular if you have to do some stuff a validator does but even more
| thorough, like checking that your DB key isn't only there but also fits
| your format restrictions, and if you know that some validation tests have
| to be checked for but are actually never triggered.
I suppose at some point the reason will have to be rediscovered why system
identifiers in notation declarations - in SGML, at least - often point to
executable code. (And, yes, XML has butchered this one.)
| How do you write large, complex DTDs without parameter entities and keep
| them maintainable?
By reconsidering the conventional wisdom that the form in which I maintain
DTDs must always be the form I pass to an SGML/XML parser. Since a DTD
can be legal without PEs, and since PEs can be preprocessed out of a DTD,
either this PE-liberated form itself is still inherently difficult to
process, or the difficulty must lie in having to process PEs (at "run
time".) The prejudice I sense applies to the former: it's a prejudice,
not only unsubstantiated but also all the more persuasive for not having
or even needing substantiation.
|> 1. No entity references.
| Good! Should be enacted immediately! (with some amendments regarding
| character references)
No amendments needed for character references. (Lumping them with entity
references just because of a similarity in delimiters is a mistake.)
| XInclude is not the same as an entity reference
I didn't say it was. I suggested that it's an examplar of the pattern of
reinvention we can expect to see.
| From an XSLT perspective, XInclude is much better than entities.
Actually, there is no difference. CONREF attributes needed reinvention,
|> 2. No data content notations.
| The rest of the WWW uses MIME types.
Conceptually, MIME types are a subset of notations.
| Why forcing everybody to declare their content types itself, possibly
| in an incompatible way?
Incompatible with what? Can you not have a URN for a MIME type? (XML is
not required to use Formal Public Identifiers, btw.)
|> Losing IDs may have implications for XPointer, but since there's no way
|> now to identify IDREF attributes either, this too is no loss.
| When I started with XML I thought IDs are great.
They are, when you need them.
| I need names which are unique over a *set* of documents. IDs are not
| sufficient for this.
They aren't even relevant to this. They serve a different purpose. (In
general, if you've never seen the need for IDREF attributes, then you've
probably never needed ID attributes. A wholesale importation of DB-think
is a surefire way to go wrong here.)
|> So, the news is uniformly good for implementors. Go for it!
| Yes! Yes! YES! :-)
Be careful what you wish for.
The most likely way for the world to be destroyed, most experts agree,
is by accident. That's where we come in; we're computer professionals.
We cause accidents. -- Nathaniel Borenstein