Cart
|
[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] Re: Processing DTDs
 Arjun Ray wrote: > "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. Umm, I don't think I implied the existence of such a formalism. I was under the impression that the "no-DTD" discussion revolves around the redundancy of *any* such formalism in certain (not all) situations. > 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.) I'm not sure how Linux-OS/390 executable code is going to help me on my Win2k machine. I'm pretty sure the mechanisms provided by SGML did work well in the environment of editing and processing SGML documents in a controlled environment, but we are talking about sending data over networks to clients outside the enterprise and similar stuff. > | From an XSLT perspective, XInclude is much better than entities. > > Actually, there is no difference. CONREF attributes needed reinvention, > after all. Entities have to be resolved by the parser, there is no way to pass them downstream because there are no entities in the logical data model. An XSLT processor is never goint to see any entities from an upstream processing unit. Likewise, an XSLT processor can't produce entity definitions nor references to pass them downstream. XInclude elements can be created, and, provided it is accepted as an standard passed to an XSLT processor. I don't see what this has to do with CONREF attributes. Regarding CONREF: XML is no longer about single logical documents, perhaps split into several physical documents, but still processed as a whole. There is a possiblity that someone wants to XInlude the result of a web service call, looking up the name of a city from a ZIP code. The web service has an URL, not an ID. > | 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.) I had started with IDs and IDREFs. IDs are great as long as you have one logical document, and you use entities for physically splitting it. I used XML for describing interfaces. There are several hundred interface thingies for a total 1.5MB of data. Putting this into one file is too much for the XML editors I used. Putting every thingy into it's own file was not a real solution either: changing the master file with the entity declarations in the internal subset and the references in the body is more bothersome than i like, apart from the problems with the XML editor and various tools who didn't like this approach very much. Also, because the thingies were edited independently now, allocating IDs became a growing nightmare. Moreover, there were requirements to specifiy some thingies and produce a file with them and all thingies they depend on. Creating this by hand is painful. The whole problem disappeard after I switched to my own reference elements and used XSLT, in particular document(), for doing the merge. After this, I soon realized that xsl:key is much more powerful and flexible than IDs. With XSLT at the core of the toolset, the need for IDs and entities disappears. 
|
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
|
|||||||||
