Hi Liam, thanks for your thoughts! On 3 Jan 2023, at 07:04, Liam R. E. Quin <liam@fromoldbooks.org> wrote: > On Tue, 2023-01-03 at 05:24 +0000, Ford Bryan wrote: >> Hi everyone, >> >> I thought this new blog post might be of interest to members of this >> mailing list: >> >> MinML: concise but general markup syntax >> https://bford.info/2022/12/28/minml/ > > The strength of XML, the biggest strength, is that the syntax, despite > its warts and quirkiness, works everywhere. Pretty much every > programming language has at least one XML parser, and the degree of > interoperability is unparalleled. I fully agree that XML’s strength is its interoperability and ubiquity — and I think that giving it a more modern, convenient, optional and cross-convertible meta-syntactic “skin” like MinML would further support those strengths rather than working against those strengths. I don’t see MinML as looking to replace XML, at all, just give it a more convenient facelift for users who write or read it manually. The existing syntax might, basically forever, remain the “archival” and “wire” format for XML-structured data, with MinML being an optional “front-end presentation” syntax that gets converted to traditional XML after manual entry (e.g., as website generators like WordPress and Hugo already do with formats like Markdown). For archival/transmission efficiency purposes, there are already binary/compressed XML formats aplenty, which similarly play a different role and MinML would not be intended to replace either. They are complementary, not trying to replace XML. > Previous work in this area includes ftanml (there's a Balisage paper > about that one at least) but it's very hard to get any traction. > Markdown succeeded precisely because it doesn't have complex rules - > although as soon as you get into anything complex Markdown falls over > and feebly kicks its legs in the air like a Corgi on Valium. Thanks for the pointers! I’ll look at them more deeply. From a first quick look at FtanML, I see some obvious parallels (e.g., getting rid of end tags for greater conciseness), but the overall goals are quite different: i.e., a complete “ground-up redesign” of markup rather than just a new meta-syntactic skin preserving compatibility with the same basic structure. In this respect, MinML is much “less ambitious” than FtanML, but more backward-compatible and hence more interoperable and synergistic with traditional XML. It’s not clear that you could cross-convert FtanML to/from XML, whereas reliable automatic cross-conversion (i.e., semantic compatibility and preservations of all the same tags and basic structure) is a key goal for MinML. > It also looks as if, confusingly, the HTML character entities are built > in to your proposal, instead of the usual XML mechanism of defining > one's own? It’s true that the current early prototype proposal and implementation slightly-uncomfortably “mixes” a few things that should (and I think will) operate at separate levels. In particular, the “basic MinML” syntax that I think is most important does not and should not care what character entities exist or where they were defined. My current prototype implementation, however, for the sake of immediate usability, incorporates a couple features that should probably be at a different layer: e.g., the particular character references it currently provides should be considered part of “MinML-styled HTML”, not part of the “basic MinML” meta-syntax itself. The same goes for the double-quote substitution syntax “[quote], which definitely shouldn’t be part of “basic MinML” per se but should be provided, if at all, at a higher layer. Figuring out the right separation and modular structure is definitely still a work in progress. Cheers Bryan > Thank you for sharing your ideas. > > > liam > > > -- > Liam Quin, https://www.delightfulcomputing.com/ > Available for XML/Document/Information Architecture/XSLT/ > XSL/XQuery/Web/Text Processing/A11Y training, work & consulting. > Barefoot Web-slave, antique illustrations: http://www.fromoldbooks.org
Attachment:
signature.asc
Description: Message signed with OpenPGP