Cart
|
[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] Processing DTDs
 "J.Pietschmann" <j3322ptm@y...> 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 
|
PURCHASE STYLUS STUDIO ONLINE TODAY!Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced! 
Download The World's Best XML IDE!Accelerate XML development with our award-winning XML IDE - Download a free trial today! Subscribe in XML format
|
|||||||||
