Subject: Re: [xsl] Adding entity declarations to DOCTYPE in xml output From: "Wendell Piez wapiez@xxxxxxxxxxxxxxx" <xsl-list-service@xxxxxxxxxxxxxxxxxxxxxx> Date: Wed, 27 Feb 2019 01:22:50 -0000 |
Hi, Agreeing with everything Eliot is saying, but looking at the glass half full. Just because a feature is there does not mean we need to use it - or use it for/as intended. I am not above using a parsed entity for an easy hack. But I am not, these days, expecting to recommend it as a feature in a system. For all the reasons Eliot says and more. On topically, it is a demonstration in itself that XSLT plugged the hole left if, in 1999 or so (about when it became usable), you needed an inclusion mechanism, and couldn't or wouldn't use entities for whatever reason. Yet at the same time, there were systems up and running including precursor systems of Michele's EAD stack, which availed themselves of this feature even to the point of depending on it for key functionality -- because there was no XSLT and no other recommended way to turn syntax into boilerplate or perform other sorts of easy and necessary substitutions of text or even markup. Because SGML had no XSLT (we leave aside the four or six brave visionaries who did this all in DSSSL, which would include Eliot Kimber maybe one or two other readers), perforce it needed entities. Because SGML offered entities, EAD had entities, and because EAD was SGML and XML carried that legacy forward onto the web, it was easier for EAD to become XML -- especially as it did not have to retool its entire stack, or move to something that didn't exist yet (XSLT) or wasn't 'proven' (DSSSL even if Eliot had already proven it, or any number of other solutions that might have been offered then or since). So because it made it easier for EAD (or name-your-vertical SGML application) to migrate to XML, entities came along with it. Tail wagging dog? Thus evolution lurches forward. It is not at all clear in retrospect that this was not a correct choice strategically, even if it has left us with technical debt of some nature. See the thing is, Michele's application is still running. I call this a success. It has probably paid for itself, is one way of putting it, plus dividends. Had external parsed entities or internal DTD subsets been dropped from XML -- who knows what else we might have lost along the way? On the other hand, if you are designing a system today and you need boilerplate expansion? Just look at DITA or any of a half dozen other improved approaches. I think it was a help that XML could support named character entities, e.g. & ldquo ; & mdash ; and the like. Since people were already used to them from HTML. Cheers, Wendell On Tue, Feb 26, 2019 at 5:47 PM Liam R. E. Quin liam@xxxxxxxxxxxxxxxx <xsl-list-service@xxxxxxxxxxxxxxxxxxxxxx> wrote: > > On Tue, 2019-02-26 at 21:53 +0000, Eliot Kimber ekimber@xxxxxxxxxxxx > wrote: > > That general requirement (simple string macros) can be satisfied > > using XInclude, which is implemented by most, if not all, of the > > modern XML parsers. > > Pretty much. It's unfortuate that we never added control over XInclude > processing to the doc() function in XPath/XQuery/XSLT/... > > > I could go farther and say that the original SGML design of DTDs was > > entirely misguided as well and should never have been done that way > > and certainly shouldn't have been carried into XML (again, I > > certainly argued *for* them at the time) > > It's questionable as to have far from SGML we could have taken XML and > had it go anywhere. As it was for a while i was getting daily calls > from someone called Charles opposed to making DTDs optional :-) > > > > but that's easy for me to say now. At the time that SGML was being > > defined and implemented the DTD syntax seemed perfectly sensible and > > it took a long time for us to recognize the inherent problems with > > DTDs as they exist in SGML and XML. > > > > In particular, because they are a purely syntactic mechanism DTDs are > > a security risk and provide no reliable declaration of the actual > > semantic document type of the document that exhibits the DOCTYPE > > declaration. > > You're right - public identifiers do *not* do what many people think, > and neither does a DOCTYPE declaration. A combination of a namespace > URI and a version attribute seems better, but is still not perfect. > > It always bugged me that SGML DTDs didn't guarantee a particular root > element. Yuribs take was to point out that he could write a book > starting with a single paragraph and working outwards, and have the > document remain DTD-valid at all times. But that just says that SGML > needed a separate concept of document-valid alongside what-you-have- > here valid. > > Liam > > > -- > Liam Quin, https://www.delightfulcomputing.com/ > Available for XML/Document/Information Architecture/XSLT/ > XSL/XQuery/Web/Text Processing/A11Y training, work & consulting. > Web slave for vintage clipart http://www.fromoldbooks.org/ > -- Wendell Piez | wendellpiez.com | wendell -at- nist -dot- gov pellucidliterature.org | github.com/wendellpiez | gitlab.coko.foundation/wendell - pausepress.org
Current Thread |
---|
|
<- Previous | Index | Next -> |
---|---|---|
Re: [xsl] Adding entity declaration, Liam R. E. Quin liam | Thread | Re: [xsl] Adding entity declaration, Liam R. E. Quin liam |
Re: [xsl] Adding entity declaration, Liam R. E. Quin liam | Date | Re: [xsl] Adding entity declaration, Liam R. E. Quin liam |
Month |