[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] Re: Re: LPDs
On 05/08/2021 15:43, Marcus Reichardt wrote: ... To clarify, an SGML parser merely passes all applicable link rules in a given context to "the application" which is then expected to select a matching one in case there's more than a single. SGML merely verifies weak uniqueness of link rule declarations (namely that if more than a single link rule applies to a given element in a given link set, all of these link rules must have link attributes). Along the same lines, SGML under no circumstances can re-parse content based on feedback of later LPD pipelining stages, nor does it need to. You quoted to me: for example, a formatter might process part of a document to generate galleys, then process part of the generated galleys, then go back to producing galleys again. An application could even use information gained during the page production process to re-do some of the earlier galley processing ... If you have recursive sections, a la DocBook's <section> [1], then you need myriad link rules to have the correct attributes added to each level of section title.SGML has the RANK feature assigning a level suffix like h1, h2, etc., We tried RANK. It was. allowing you to trivially target h1, h2 as source elements in link rules. Though it doesn't quite work as expected by most authors (doesn't assign a rank suffix automatically by nesting level), my I don't recall what our issue was, but we only tried it in one project. point with respect to this being a vocabulary issue thus stands: if you deliberately choose not to use a feature, then *of course* you must make up for it by inventing your own conventions, bringing its idiosyncrasies along. If we tried to use a feature and it made things worse, then of course we stopped using it. In the case of Docbook, dbhierx.mod went with allowing both unranked <section> elements and unranked <sect1>, <sect2>, ... (declared as individual elements) at the same time. Now I also have contributed papers where it sure was helpful to merely include/concatenate articles to produce conference proceedings irrespective of levels, I'm sorry to have touched a nerve. You brought up <sect1>, etc., but we only ever used 'unranked' sections, and we would not have had a 'renderas' attribute at all. Now of course the theoretical existence of SGML RANK doesn't help if customers bring Docbook content for printing, but it highlights a We did end up formatting DocBook manuals in multiple languages for a client, but the failed experiments with LPDs and RANK were with home-grown, document-specific DTDs. subtle difference: that the XML world is somewhat dominated by committee-designed vocabularies with a natural tendency to overreach and eventually represent each and everything under the sun, whereas We did, which relates to why RANK didn't suit us. To come back to namespaces, the original topic of this subthread :) The deeper issue with namespaces is exactly that: there's no point Yet somehow we all ended up using CALS tables, so much so that SGML Open (as it was then) defined an interoperable subset. DocBook ended up supporting both CALS <table> elements and HTML <table> elements. XSLT is a Turing-complete language. That XSLT can perform arbitrary transformations doesn't contribute to a discussion about the adequateness of a document representation language, just asI do wonder why I react so badly to LPDs after all these years while I don't have a problem with an <?xml-stylesheet?> PI in a document. I think it shows that LPDs are inadequate in comparison because LPDs can't generate different links for all the different contexts that you put in a 'match' attribute in XSLT. If all that XSLT could do was add attributes, it would still be able express far more than LPDs. If you had a RELAX NG processor that could regenerate its source document with added attributes to indicate the pattern that validated an element (or attribute), that would be more expressive than LPDs. any other Turing-complete language wouldn't. All the PI does is hide away the difficult parts in a pseudo-declarative way, with XSLT considered part of the "XML stack" to make it appear homogeneous, similar to how databases use special database languages. I am not sure what point you are trying to make. SGML had multiple transformation tools, both free and commercial. The conceptual model for XSL, from XSL 1.0 [4], includes: An XSL stylesheet processor accepts a document or data in XML and an XSL stylesheet and produces the presentation of that XML source content that was intended by the designer of that stylesheet. and: Tree transformation allows the structure of the result tree to be significantly different from the structure of the source tree. and: Formatting is enabled by including formatting semantics in the result tree... In XSL, the classes of formatting objects and formatting properties provide the vocabulary for expressing presentation intent. No mention of an XML representation. You can blame Microsoft for starting the XSLT processor trend. Under 'Transform to Another Vocabulary', there's: In some implementations of XSL/XSLT, the result of tree construction can be output as an XML document. This would allow an XML document which contains formatting objects and formatting properties to be output. This capability is neither necessary for an XSL processor nor is it encouraged. Still no mention of XSL-FO as input. When XSL 1.0 needed a testsuite to demonstrate interoperability so it could go from Candidate Recommendation to Proposed Recommendation, IIRC there was a long wait while people wrestled with the idea of allowing XSL-FO XML files in the test suite because that wasn't how XSL was supposed to work. area trees, etc. all about representing non-text (component models) in markup. But, in contrast to XSL's predecessor DSSSL, no sane person would actually use XSL to render/position flow layouts (HTML + CSS core into boxes) to another markup language, let alone without having DSSSL defined a transformation stage. Jade's non-standard SGML backend was turning into the main use of Jade. Back in that day, I wrote Scheme functions with function names corresponding to HTML element names that had parameters corresponding to their attributes so that you had something like XSLT but with parentheses and Scheme syntax. access to font metrics, and with extremely painful ways to do the calculations implemented in TeX or troff at disposal. Instead, XML XSL-FO, not FOP. FOP is an XSL formatter, but it is not the only one. XSL itself, similar to a mythical "SGML application". Actually, I Last week, at Balisage, David Birnbaum and Charlie Taylor from University of Pittsburgh gave their talk 'How long is my SVG <text> element?' [1]. They showed using XSLT to generate/modify SVG when using an XML representation of their font metrics. I've noticed somewhat of a defensive gut reaction by XML heads whenever SGML comes up. While I use XML all the time, and plan to continue doing so, let me bluntly say that XML's only raison d'etre, by the XML spec's own wording (as in chapter 1, sentence 1), was to replace SGML as a markup meta-language on the web. Likewise, the Well, no. Its goal was for generic SGML to work as well as HTML. The second sentence of the Abstract is: Its goal is to enable generic SGML to be served, received, and processed on the Web in the way that is now possible with HTML. HTML 4.01 described itself as "an SGML application conforming to International Standard ISO 8879 -- Standard Generalized Markup Language". [2] SGML was used to provide a formal definition of HTML [3], but there's no mention of other DTDs being possible (on or off the Web), and the section on validation includes: Beware that such validation, although useful and highly recommended, does not guarantee that a document fully conforms to the HTML 4 specification. The idea of 'SGML as a markup meta-language on the web' just didn't register with non-SGML people at that time. XML couldn't replace SGML as a meta-markup language on the Web because SGML wasn't being used as a meta-markup language on the Web in any significant volume at that point anyway. I'm not here to discuss whether or not XML was meant to replace SGML as a markup meta-language on the web. My only purpose in joining this conversation was to counter the notion that LPDs were a good idea. purpose of xsl-stylesheet PIs is to supply an HTML rendering for non-XHTML/non-HTML XML content in browsers (and I've actually Not just in browsers. With AH Formatter, the PI can specify an XSLT stylesheet that generates XSL-FO. implemented web sites that way, albeit not in this epoch). Its existence, in combination with XSLT being Turing-complete, can't be used as serious argument in discussing the merits and features of document languages. As to namespaces, their original purpose was to avoid name collisions in anticipation of a wealth of new RDF has nothing to do with the Web? held back HTML evolution while they were busy with XML, such that CSS had to become absurdly overpowered to cater for HTML's shortcomings, HTML being a rather simplistic vocabulary based on early common text markup tagging folklore plus hypertext anchors for casual academic publishing, with generic divs and spans used for nearly everything else. There was even the false structure-vs-presentation dichotomy created after the fact to justify a new *syntax* for rendering properties (eg CSS). In which universe does it make sense to use <p style="color: red"> rather than <p color=red>? In what world does it make sense to put the final formatting in the source document to begin with? And we're already suffering through this proliferation of microsyntax and idiosyncrasies creating browser monopolies and putting web authoring out of reach of even graphic professionals let alone layman. (Btw your XSL predicate "@rend eq 'all-small-caps'" looks suspiciously similar to the ad-hoc selector syntax in the SGML handbook ;) Just so Yes. You can find proto-versions of half a dozen things in the examples in the SGML Handbook if you are inclined to look for them, but the standard LPD mechanism didn't do enough, and all of the other syntaxes were non-standard and unimplemented. we're on the same page, if W3C's CSS WG is having their way, we'll shortly see gems such as I think that our perspectives about "<section>" differ. *when the author has complete control over the text document anyway* and could well be bothered to use specific elements to encode that which (s)he wants to express, in a markup language that excels in exactly these kind of applications of all things.Regards, Tony Graham. -- Senior Architect XML Division Antenna House, Inc. ---- Skerries, Ireland tgraham@antenna.co.jp [1] https://www.balisage.net/2021/Program.html#F14 [2] https://www.w3.org/TR/html401/ [3] https://www.w3.org/TR/html401/sgml/intro.html#h-19.1 [4] https://www.w3.org/TR/2001/REC-xsl-20011015/slice1.html#section-N639-Processing-a-Stylesheet
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] |
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
|