Re: XHTML is no longer being maintained

Ivan,


> So what does it mean when you say "QTI3 is unlikely to adopt the HTML
> syntax"? Does it mean that they will generate those narrative subtrees in
> HTML but using the XML conventions, or that they will rely on XHTML
> processing of, say, scripts, script tags, and things like that?
>

I mean that QTI3 documents (including the top-level QTI tags and
narrative HTML subtrees) parse as XML. QTI3 is not directly handled by
browsers.  Rather, it is converted to HTML and then handled by browsers.  I
am sure that QTI3 implementations rely on XML parsers very heavily.

Regards,
Makoto



> Ivan
>
>
> ----
> Ivan Herman, W3C
> Home: http://www.w3.org/People/Ivan/
> mobile: +33 6 52 46 00 43
> ORCID ID: https://orcid.org/0000-0003-0782-2704
> On Aug 19, 2024 at 12:20 +0200, MURATA <eb2mmrt@gmail.com>, wrote:
>
> I am now involved in QTI3, which is an XML-based language for representing
> assessments or tests.  Basically, the top-level structure is represented by
> QTI-specific tags while narrative subtrees are represented by XHTML.  QTI3
> is unlikely to adopt the HTML syntax.
>
>  --
> Regards,
> Makoto
>
>
> 2024年8月19日(月) 午後6:47 Hoekstra, Rinke (ELS-AMS) <r.hoekstra@elsevier.com>:
>
>> We faced a similar issue with our CP/LD standard for scholarly content (
>> https://www.niso.org/publications/z39105-2023-cpld).
>>
>>
>>
>> Originally, we settled on XHTML to ensure that we could easily process
>> the content using XML processors, but we received significant pushback from
>> various sides (especially the user-facing community). Given that there are
>> several reliable ways to process HTML into a DOM, we settled on “just”
>> HTML5.
>>
>>
>>
>> An additional benefit (for us) was that by dropping the XML, we now have
>> almost entirely stratified the content layer (HTML) from the data layer
>> (RDF). XML has too many affordances to overload content with information
>> that is really just (meta)data and should be treated as such.
>>
>>
>>
>> -Rinke
>>
>>
>>
>> --
>>
>> Rinke Hoekstra
>>
>> Sr. Director Architecture – Knowledge
>>
>> Industry Director of Elsevier’s Discovery Lab
>>
>> ELSEVIER - Amsterdam
>>
>> r.hoekstra@elsevier.com
>>
>>
>>
>> Emails can arrive at all hours, but at Elsevier we respect your personal
>> time. Feel free to respond to this email during your normal working hours.
>>
>>
>>
>> *From:* Ivan Herman <ivan@w3.org>
>> *Date:* Saturday, 3 August 2024 at 11:11
>> *To:* Alyssa Riceman <alyssaricemanepub0@mailbox.org>, Brady Duga <
>> duga@ljug.com>
>> *Cc:* public-publishingcg@w3.org <public-publishingcg@w3.org>
>> *Subject:* Re: XHTML is no longer being maintained
>>
>> **** External email: use caution ****
>>
>>
>>
>> On Aug 2, 2024 at 21:34 +0200, Brady Duga <duga@ljug.com>, wrote:
>>
>> Switching away from XHTML to HTML has been a topic for years in the
>> various EPUB related groups. From a reading system perspective, most RSes
>> load their content into webviews or the browser as HTML anyway, since XHTML
>> has been finicky since ... well, since forever. But there are parts of the
>> pipeline in almost all RSes that assume they are getting well-formed XML,
>> so we have never gone the route of allowing it as a core media type. Every
>> once in a while there is a bit of a push when something breaks (e.g.
>> scripting has some XHTML issues), but the cure has always been worse than
>> the disease. Maybe the time has come (or is coming) to bring it up again.
>>
>>
>> There have been extensive discussions around EPUB + HTML over the years,
>> see, for example:
>>
>> https://github.com/w3c/epub-specs/issues/636
>> https://github.com/w3c/epub-specs/issues/2259
>>
>> The fear has always been to break the existing infrastructure, which does
>> not only involve Reading Systems, but also the full production line, epub
>> checkers, etc.
>>
>> That being said, spawning XHTML into a separate group does not seem to be
>> realistic. With the complexity of HTML today, that would be an impossible
>> task, and would almost surely lead to an incompatible branch off HTML.
>> Eventually, the EPUB community at large may have to finally bite the bullet
>> and open up to HTML but, so far, this has not been the case...
>>
>> Cheers
>>
>> Ivan
>>
>>
>> On Fri, Aug 2, 2024 at 12:14 PM Alyssa Riceman <
>> alyssaricemanepub0@mailbox.org
>> <https://mailto:alyssaricemanepub0@mailbox.org/>> wrote:
>>
>> Hi!
>>
>> According to modern editions of the HTML Living Standard (
>> https://html.spec.whatwg.org/multipage/xhtml.html):
>>
>> > the XML syntax is essentially unmaintained — in that, it’s not expected
>> that any further features will ever be added to the XML syntax (even when
>> such features have been added to the HTML syntax).
>>
>> (Where 'the XML syntax' is XHTML.)
>>
>> This seems worrying! One of the great advances of modern EPUB over the
>> format's earlier versions was unpinning the versions of its core media
>> types, allowing use of—among other things—arbitrarily-modern HTML in our
>> XHTML content documents (within the limits of what readers will
>> realistically be able to handle); but now here we are getting stuck on the
>> path to outdatedness anyway, for our XHTML content documents, on the basis
>> that they no longer will be modern HTML.
>>
>> (Indeed, I've already personally run afoul of a case where this is
>> relevant: XHTML, unlike modern HTML, lacks support for Declarative Shadow
>> DOM, which I'd been hoping I might be able to make use of in a
>> currently-ongoing EPUB-related project of mine.)
>>
>> I don't know what, if anything, it would make sense to do about this. The
>> ideal, of course, would be to magically produce some new maintainers for
>> HTML's XML syntax so it can be returned to consistent up-to-date-ness with
>> non-X HTML; but that seems likely to be difficult, potentially to the point
>> of logistical infeasibility, and no other possible solutions have yet
>> occurred to me which seem any more feasible than that one.
>> (Likely-less-feasibly, of course, there's some temptation towards allowing
>> use of non-XML-syntax HTML within EPUB; but that seems, from my
>> admittedly-limited knowledge, likely to be an impractical path to go down
>> which would inflict large amounts of difficulty on developers of reader
>> software.)
>>
>> Still, even absent immediate knowledge of a solution, it seems like a
>> concern worth raising to the group's attention, and (as far as I can tell
>> from skimming the group archives) not one which has already been raised by
>> anyone else. So here it is. Does this appear to be a real problem to others
>> here as it does to me? And, if so, are there any potential solutions I've
>> missed which are apparent to others here and worth pursuing in more depth?
>>
>> Thanks,
>> Alyssa Riceman
>>
>>
>>
>>
>>
>> ------------------------------
>>
>> Elsevier B.V. Registered Office: Radarweg 29, 1043 NX Amsterdam, The
>> Netherlands
>> <https://www.google.com/maps/search/Radarweg+29,+1043+NX+Amsterdam,+The+Netherlands?entry=gmail&source=g>,
>> Registration No. 33158992, Registered in The Netherlands.
>>
>

-- 
 --
慶應義塾大学政策・メディア研究科特任教授
村田 真