OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help



   Processing DTDs

[ 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


News | XML in Industry | Calendar | XML Registry
Marketplace | Resources | MyXML.org | Sponsors | Privacy Statement

Copyright 2001 XML.org. This site is hosted by OASIS