[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] Re: Improving XML desing?
Chris Burdess said: My interest in this list is for discussing if some of ideas developed from the CanonML program can be implemented in a future XML specification. I am not interested in debate about weakness or strengths of the CanonML approach here. If anyone is interested, any comment on improvement of CanonML would be directly attached to the corresponding Canonical Science Today and then debated there. I will not reply any other message as this from Chris Burdess here. Since this message was already published in the list before remarks above, I will reply to this one. > <juanrgonzaleza@c...> wrote: >> In >> >> [http://canonicalscience.blogspot.com/2006/04/canonml-markup- >> language-beyond-tex-xml.html] >> >> i presented some basic thoughts on CanonML, a markup language >> beyond TeX, >> XML, and alternatives as liminal, GODDAG, SGML concur, and others. >> The new >> approach is clearly inspired in SXML. > > Many people have already commented that s-expressions are more > concise than XML. The standard rebuttal is that with deeply embedded > tree structures it is virtually impossible to visually locate the end > tag and therefore know which element ends where. I addressed this topic with care and even provided several examples in Canonical Science Today of why readability of XML end tags is in most of cases a myth. > Therefore, for > trivial examples s-expressions are more readable, whereas for more > complex examples XML is much more readable. Already replied. > CanonML appears to be yet > another s-expression language, with confusing additional syntax that > appears to serve no purpose (such as double colons), redundant > duplication of forms ([::x] versus \x). It introduces not only the > above problem but also Incorrect. It is not based in s-expressions. The reasons for introducing explicit tag and advantages over s-expression based markups were discussed. The relationship between [::x] and \x is like <tag></tag> vs <tag/> but with additional advantages. For instance, it is trivial to write a parser understanding also CanonML empty tags, whereas is not so trivial in XML. This is the reason of the elimination of empty tag syntax in some approaches as simple or minimal XML. Still, people worried about empty tags (trying to write a still simpler parser) could develop a minimal CanonML subset without empty tags notation. I already wrote about that. > > - confusion over whether whitespace is part of the text content or the > markup (a step backward from SXML) False. It is the XML WS model is very ugly. One of authors of MSXML recognized that WS is one of the ?perpetual nightmares? of XML. Difficulties addressed by him (extracted from real-life XML code) are avoided in this approach. Moreover difficulties arising in mixed content with SXML are not present here. WS model is also improved over TeX-like approaches. Since WS is an important point I thought talk about the CanonML model in a separate posting in a future Canonical Science Today. > - lack of processing instruction mechanism False. > - lack of comment mechanism False, and as in liminal there is not restrictions to usage of "--" prohibited in XML. > - lack of character encoding mechanism False. Moreover, I work in Unicode by default. > - lack of reusable entity mechanism False. Moreover the specific module CanonFormal contains more symbols that are listed in the predefined MathML entities. There is others improvements are not achieved even if list of MathML entities is enlarged. > - lack of mechanism for modularity of documents (within different > resources) I do not understand what you exactly mean. > - lack of differentiation between unordered and ordered properties > (XML attributes vs. child elements) Irrelevant for practical applications. What is the advantage of lack of differentiation between <T a="1" b="2"/> and <T b="2" a="1"/> in XML? However, lack of ordered metadata is a real problem in real usage. Attribute model in CanonML was improved beyond ConciseXML (which is already a generalization of XML 1.0-1.1). > >> Some of technical points of CanonML are beyond XML (i mean if one wait >> backward compatibility with XML 1.0-1.1), but other points could be >> considered for discussion on a future XML specification. > > Not with your current proposal. The only advantage I can see to your Interestingly, Paul T -who know near 100 alternatives to XML- defined this approach as "Strong (the only?) attempt on one markup for several xml processing specs design" > language is that it may be slightly more readable for some small class > of trivial documents. Now let's consider a more reasonable example: > > <math xmlns='http://www.w3.org/1998/Math/MathML'> > <mrow> > <mo fence='true'>∥</mo> > <mrow> > <msup> > <mi mathvariant='bold'>v</mi> > <mi>L</mi> > </msup> > <mo>-</mo> > <msubsup> > <mi mathvariant='bold'>w</mi> > <msup> > <mi>c</mi> > <mi>L</mi> > </msup> > <mi>L</mi> > </msubsup> > </mrow> > <mo fence='true'>∥</mo> > <mo>≤</mo> > <mo fence='true'>∥</mo> > <mrow> > <msup> > <mi mathvariant='bold'>v</mi> > <mi>L</mi> > </msup> > <mo>-</mo> > <msubsup> > <mi mathvariant='bold'>w</mi> > <mi>i</mi> > <mi>L</mi> > </msubsup> > </mrow> > <mo fence='true'>∥</mo> > <mo>∀</mo> > <mi>i</mi> > </mrow> > </math> > > Let's try this in CanonML: > > [::math [@ [::xmlns http://www.w3.org/1998/Math/MathML]] [::mrow [::mo > [@ [::fence true]] â?¥] [::mrow [::msup [::mi [@ [::mathvariant bold]] > v] [::mi L]] [::mo -] [::msubsup [::mi [@ [::mathvariant > bold]] w] [::msup [::mi c] [::mi L]] [:mi L]]] [::mo [@ [::fence > true]] â?¥] [::mo â?¤] [::mo [@ [::fence true]] â?¥] [::mrow [::msup > [::mi [@ [::mathvariant bold]] v] [::mi L]] [:mo -] [:msubsup [::mi [@ > [:mathvariant bold]] w] [::mi i] [::mi L]]] [::mo [@ [::fence true]] > â?¥] [::mo â??] [::mi i]]] > > Shorter, yes. But more readable? I know which one I'd prefer to debug > the nesting of (and edit using vi over an ssh connection). Where does > the second mrow element end, for instance? The third? Apples and oranges? Let me ignore now that your above example is not CanonML way to encode MathML code (you are copying the SXML attributes list!). Let me ignore the problems of XML end tags on data storage verbosity and dynamical execution issues i addressed. Let me ignore also that there exists a specific module for math improving MathML. Let me ignore others advantages of CanonML over XML. Let me also ignore the difficulties with MathML predefined entities (e.g. we discussed certain difficulties about ⅆ in w3c math mailing list this year and final advice from several w3c folks was to not use it). The MathML code without extra WS is <math xmlns='http://www.w3.org/1998/Math/MathML'><mrow> <mo fence='true'>∥</mo><mrow><msup> <mi mathvariant='bold'>v</mi><mi>L</mi></msup><mo>-</mo> <msubsup><mi mathvariant='bold'>w</mi><msup><mi>c</mi><mi>L</mi> </msup><mi>L</mi></msubsup></mrow> <mo fence='true'>∥</mo><mo>≤</mo> <mo fence='true'>∥</mo><mrow><msup> <mi mathvariant='bold'>v</mi><mi>L</mi></msup><mo>-</mo><msubsup> <mi mathvariant='bold'>w</mi><mi>i<mi/>L</mi></msubsup> </mrow><mo fence='true'>∥</mo><mo>∀</mo> <mi>i</mi></mrow></math> whereas "your CanonML" code re-typed with extra WS (there is different ways to improve readability) looks like [::math [@ [::xmlns http://www.w3.org/1998/Math/MathML]] [::mrow [::mo [@ [::fence true]] ∥] [::mrow [::msup [::mi [@ [::mathvariant bold]] v] [::mi L] ] [::mo -] [::msubsup [::mi [@ [::mathvariant bold]] w] [::msup [::mi c] [::mi L] ] [:mi L] ] ] [::mo [@ [::fence true]] ∥] [::mo ≤] [::mo [@ [::fence true]] ∥] [::mrow [::msup [::mi [@ [::mathvariant bold]] v] [::mi L] ] [:mo -] [:msubsup [::mi [@ [:mathvariant bold]] w] [::mi i] [::mi L] ] ] [::mo [@ [::fence true]] ∥] [::mo ∀] [::mi i] ] ] Nice? Maybe. More readable than XML? Sure! Where does the second mrow element end? The third? Easy! (even *without* a syntax highlighting or good editor) Ask if you do not know the hint. Not so easy in XML, because difference between open and end tags is only of one character in 6-7 (this was one of improvements of liminal over XML in its design of closed tags). However, I did an error whereas copying above XML fragment without WS. Can you find it in the MathML code? P.S: the fragment is XML valid, therefore a XML parser do not help you. > -- > ç?¬ Chris Burdess > "They that can give up essential liberty to obtain a little safety > deserve neither liberty nor safety." - Benjamin Franklin Juan R. Center for CANONICAL |SCIENCE)
|
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
|