[
Lists Home |
Date Index |
Thread Index
]
"J.Pietschmann" <j3322ptm@yahoo.de> 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
| ressources.
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,
after all.
|> 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
|
