Re: Second International Symposium on Invisible XML

Hi again and please feel free to skip (this is only for those still
reading),

- In my own judgment, the title "International Symposium on Invisible
Markup" makes a good title, and does not need a subtitle. I acknowledge
this leaves it requiring some explanation, as many titles do, and trust
that it will appear frequently with language that puts iXML at the front
and top. I also like the old (shorter) title better than the proposed
title-with-subtitle, assuming other elements are good. But none of them is
a disaster. Naming is hard and we can talk a long time about names.

FWIW I also think it is entirely likely that most people who know about it
or care will continue talking, and writing, about the "iXML Symposium", no
matter what it is named. And that is a good thing and an asset for us. It
can have an official name but that won't change its identity or how it is
known. "Symposium" was an excellent word choice for this reason.

- Bethan has also said this:

> I believe I have reiterated my enthusiasm for non-IXML approaches to
invisible markup almost ad nauseam, and I've seen nobody else disagree, but
I'm happy to reassure you that - as far as I have any say in the matter -
you and your non-IXML work should absolutely feel welcome at the symposium.
That is, after all, why I agreed many tens of messages back that changing
the title was a good idea.

This is good, but it leaves me at a loss. Bethan's sincerity here is plain,
and I am glad (and a little relieved) that (to her mind anyway) I should
feel welcome. As should (as I also imagine she would agree) any outlier or
doubtful case, assuming we make the effort, bring the goods and play by the
rules. Awesome -- but this thread hasn't said anything of the sort, or if
it has, the message has been completely lost on me in the cascade. I cannot
help but feel we need to do a better job of that. So thank you for saying
it. As long as my project has iXML inside the black box (as it does
currently) I think I should still be okay, even if it is deep inside the
circuitry. Now I have a better basis for assuring others similarly -- or
warning them, as need be.

The Irish guy I met in New Jersey last month who was designing his own
Markdown with his own parser in Rust, would he be welcome? Not an
XML-hater, he just didn't know very much, or not yet. I *think* so, maybe?
or only to listen?

Regards, Wendell


On Fri, Aug 21, 2026 at 2:42 PM Bethan Tovey-Walsh <bytheway@linguacelta.com>
wrote:

> 
>
> Goodness, now we really are splitting hairs.
>
>
> Gracious! I really don't think *I* am.
>
> IXML requires a grammar which describes two things:
>
> a) a language consisting of one or more strings (which may include the
> empty string) that can be recognized by the grammar;
>
> b) the method for constructing an XML document, when the processor is
> given, as an input, any of the strings belonging to its language.
>
> All of this is possible because the IXML spec tells us how to describe
> major XML structural elements and their relationships using a grammar, and
> (optionally, though most IXML grammars also do this) how to fit (parts of)
> an input string into the XML structure that has been described.
>
> To implement an IXML processor, it is both necessary and sufficient that
> one implement the IXML spec. At the moment, that means implementing the
> rules for constructing XML from a grammar and an input, including various
> extra-grammatical rules such as the rule forbidding repeated attribute
> names.
>
> Norm's implementation can output JSON and CSV. Ronald and David's
> implementation, as I understand it, will be capable of outputting next-gen
> markup formats. These implementations also implement the IXML spec. So they
> are IXML processors, with added functionalities of various kinds. That's
> awesome.
>
> But I don't believe it's splitting hairs to correct the misconception that
> conformant IXML processors are somehow format-agnostic. It's a fairly major
> misconception, it's one that's come up in the past, and it leads people to
> mistaken assumptions about what IXML is and does. In particular, it may
> lead to the assumption that "IXML" and "invisible markup" are basically
> synonyms, rather than the former being a hyponym of the latter.
>
> It's starting to feel to me as though the goalposts have moved so much
> during this conversation that they've wandered right off the field and are
> currently looking for the bus station so they can go visiting their
> goalpost friends in the next state.
>
> So let me restate my position on the matter at hand:
>
> 1. "Symposium on Invisible Markup" should be the main conference title, to
> make clear that IXML isn't our sole focus and that all kinds of
> invisible-markup-related approaches are welcome and wanted.
>
> 2. "IXML" should be in the symposium's subtitle, for reasons of
> discoverability and because IXML is, by a country mile, the most prominent
> and popular example of "invisible markup", whereas "invisible markup"
> itself is not yet well-known as a term of art.
>
> So let me put it more bluntly: should I feel welcome at the iXML
> conference, if my work is with a non-XML technology, or even a workalike
> (rival) technology to iXML?
>
>
> I believe I have reiterated my enthusiasm for non-IXML approaches to
> invisible markup almost ad nauseam, and I've seen nobody else disagree, but
> I'm happy to reassure you that - as far as I have any say in the matter -
> you and your non-IXML work should absolutely feel welcome at the symposium.
> That is, after all, why I agreed many tens of messages back that changing
> the title was a good idea.
>
> Regards,
>
> BTW
>
>
> Sent from my iPhone
>
> On 21 Aug 2026, at 18:01, Wendell Piez <wapiez@wendellpiez.com> wrote:
>
> 
> Bethan,
>
> Goodness, now we really are splitting hairs.
>
> Norm's non-standard curly-braces emission feature does not disqualify his
> processor from being an iXML processor, as conformance does not require
> that no optional features be offered. You did not say it did -- but neither
> have I proposed that iXML be removed from the name of iXML, or that XML
> be removed from the name of iXML, or from iXML itself, or that XML isn't
> important and foundational.
>
> I can agree with everything in your latest email, and still not agree that
> putting "iXML" into the title of the conference is an open-and-shut case
> with an obvious answer. Even for an iXML conference!
>
> Here is the current statement of the conference's scope (pasted from
> invisiblexml.org). With respect, I think it's a little soft around the
> edges regarding the question at hand:
>
> > Invisible XML (ixml) is a language and process for identifying structure
> in documents. Invisible markup allows users to exploit the implicit
> structures in documents without the need for explicit markup. Since the
> release of the ixml standard in 2022, we have seen a steady increase in the
> use of ixml, as well as many interesting conference presentations about the
> language. The community group felt the time was right for an event
> exclusively dedicated to invisible markup.
>
> I think this softness is good, making the (iXML) focus clear without
> imposing constraints on what people might wish to bring. But now I am
> wondering if you agree with me (that the softness is good). So let me put
> it more bluntly: should I feel welcome at the iXML conference, if my work
> is with a non-XML technology, or even a workalike (rival) technology to
> iXML?
>
> I mean, your answer might be "no, you are not really welcome". But imagine
> if one or two important JSON influencers had come to an XML conference when
> it might have made a difference. I doubt there would be less JSON, but
> there might be less stupidity.
>
> Thanks, Wendell
>
>
> On Fri, Aug 21, 2026 at 11:52 AM Bethan Tovey-Walsh <
> bytheway@linguacelta.com> wrote:
>
>> But iXML isn't constrained to emit only XML!
>>
>>
>> Currently, it is. The specification requires that an iXML processor
>> should produce XML. Some implementers offer other serialization formats as
>> a convenience, but those aren't standardized.
>>
>> XML's constraints shape what IXML is and what it can do. For example, you
>> can write an IXML grammar that could create more than one attribute with
>> the same name, but a conforming processor will throw an error if the
>> combination of input and grammar actually requires it to create an XML
>> element with multiple attributes of the same name.
>>
>> I agree that "invisible markup" is wildly exciting, and I'm particularly
>> interested in coming up with new specifications that can handle different
>> types of markup natively. But IXML is shaped by XML, and its only standard
>> output format is XML. It's far from being the format-agnostic "invisible
>> markup" your description implies, Wendell.
>>
>> Best,
>>
>> BTW
>>
>> ****************************************************
>>
>> Dr. Bethan Tovey-Walsh
>>
>> linguacelta.com
>>
>> Golygydd | Editor geirfan.cymru
>>
>> Croeso i chi ysgrifennu ataf yn y Gymraeg
>>
>> On 21 Aug 2026, at 15:24, Wendell Piez <wapiez@wendellpiez.com> wrote:
>>
>> 
>> Hello again,
>>
>> Reading Elisa's latest it sounds like her students wouldn't actually hate
>> "Invisible Markup". And they taste a new kind of acronym salad almost every
>> week.
>>
>> She also adds --
>>
>>   "unless you’re wanting to expand this to be a universal grammars
>> conference. That could be very exciting too?"
>>
>> What makes iXML ("Invisible XML") a good name for the technology is that
>> it leverages the reputed universality ("extensibility") of XML, while it
>> builds into the name the inevitable question ("what's it have to do with
>> XML?") with a very satisfying answer. XML constrains your results, not your
>> inputs. iXML doesn't make you lock into XML: it's the opposite. Part of the
>> universality of XML is its capability to be easily migrated into the tree
>> structure of your choice, including popular tree-shaped serializations.
>> Even people who hate XML, if they know anything at all about it, often know
>> this much.
>>
>> But iXML isn't constrained to emit only XML! That's only a default, a
>> convenience, and a huge fulcrum for leverage by any developer who knows how
>> to push lightly on the far end.
>>
>> In view of that fact, and of the fact that (we are agreeing, I think) not
>> to "hide" iXML but to put it in lights -- can't we consider having a
>> universal grammars conference? Are we afraid of who might come?
>>
>> Cheers and thanks again for further indulgence -- Wendell
>>
>>
>> On Thu, Aug 20, 2026 at 10:42 PM Beshero-Bondar, Elisa Eileen <
>> eeb4@psu.edu> wrote:
>>
>>> The only thing I have to say to this is just that I know some “young
>>> people”, who didn’t grow up with XML before I knew them, and who:
>>> 1) enjoy learning XML and Relax NG
>>> 2) enjoy what they can do with IXML.
>>>
>>> The second is maybe a smaller subset of the first, but the young people
>>> who take to ixml tend to go on and build remarkable projects, and they
>>> really benefit from having a conference / symposium opportunity like this.
>>> Please keep them in view. Every time these technologies are taught, we find
>>> that people mainly tend to enjoy what they are learning.
>>>
>>> I write this while I really need to be preparing the syllabus for my
>>> undergraduate Text Encoding class for this fall, and while hoping to see
>>> students who still want to learn for themselves this year, just like last
>>> year. I have some evidence that people like learning this material and
>>> appreciate seeing what professionals do with it. So much so that I might be
>>> bothering some of you to be guest speakers sometime. :-) If young people
>>> like this esoteric stuff, perhaps defining conferences as opportunities for
>>> sharing work in ixml isn’t so bad.
>>>
>>> Also, people really want to know what the “invisible” stuff is about. I
>>> think “Invisible XML” is well named to draw the curious and the markup
>>> geeks, and I still don’t really understand the desire to stretch ixml to
>>> something it’s not designed for, unless you’re wanting to expand this to be
>>> a universal grammars conference. That could be very exciting too?
>>>
>>> Just host it, and we’ll join. But I hope XML is celebrated throughout
>>> the event, even and especially as a format supporting transforms to
>>> everything else.
>>>
>>> Elisa
>>>
>>> Elisa Beshero-Bondar, PhD (she/they)
>>> TEI Technical Council Chair
>>> Development site: https://newtfire.org
>>> Program Chair of Digital Media, Arts, and Technology | Professor of
>>> Digital Humanities |  Director of the Digital Humanities Lab at Penn State
>>> Erie, The Behrend College
>>> ------------------------------
>>> *From:* Peter Flynn <peter@silmaril.ie>
>>> *Sent:* Thursday, August 20, 2026 6:02 PM
>>> *To:* ixml <public-ixml@w3.org>
>>> *Subject:* Re: Second International Symposium on Invisible XML
>>>
>>>
>>> On 20 August 2026 17:16:03 Bethan Tovey-Walsh <bytheway@linguacelta.com>
>>> <bytheway@linguacelta.com> wrote:
>>> > Can you please outline these other considerations, which make you >
>>> think that the symposium title would be better without IXML in it? Guilty
>>> as charged. My concern for not having XML in the title (but definitely in
>>> the subtitle) was the very large number of people whose response to the
>>> term "XML" is "Oh not that pointy-bracket gibberish again" (virtually every
>>> developer I encounter: Liam's #5). I'm not exaggerating, but perhaps they
>>> are by definition not in scope, so I am happy to withdraw my concern.
>>> I wonder what would happen if we ran a symposium on Invisible JSON?
>>>
>>> Peter
>>>
>>
>>
>> --
>> ...Wendell Piez... ...wendellpiez.com...
>> ...pellucidliterature.org... ...raventracks.org...
>> ... xproc.zone... ...github.com/wendellpiez...
>>
>>
>
> --
> ...Wendell Piez... ...wendellpiez.com...
> ...pellucidliterature.org... ...raventracks.org...
> ... xproc.zone... ...github.com/wendellpiez...
>
>

-- 
...Wendell Piez... ...wendellpiez.com...
...pellucidliterature.org... ...raventracks.org...
... xproc.zone... ...github.com/wendellpiez...