<scribe> scribe: chaals

<dauwhe> https://github.com/w3c/apa/issues/9

<elundberg> Hi! Is this the channel for the DSLs breakout session?

<dauwhe> elundberg: indeed!

<elundberg> Thanks!

APA issue

JS: We hear in accessibility from the math on the web community group, and we realise that there is maths, physics, chemistry, and linguistics, and music, and ...
... each has semantics and symbolic representation that we need to be able to work with for accessibility, and manipulate and interact with them.
... The Web developer community is probably the wrong community to do this, and the Assistive Technology community likewise, because they don't have domain expertise needed to check they are representing the given area of knowledge.
... how do we get the basics set up by domain experts in a way that we can help web people do finishing work...

dauwhe: Many of these domains are old (centuries), and as publishers we get content. How do we get that to the web?
... MathML is an example of this use case. It is problematic to use it on the web, because of support issues… are there some principles we can apply to different domains that we need to present, because we now need to put it on the web. And with accessibility, mobile presentation, voice assistants can work with it, etc.

IH: The more general question is that we have to accept the browsers don't solve all the miseries of the world. They will not implement all these things by themselves, so we need good stable well-documented ways to extend the browser functionalities.

[+1 to Ivan]

IH: I played with web components, and it is easy to do. But it i a moving target.
... These types of extensions are not well-documented, so people who are domain experts not web experts don't know where to start and how to handle it.
... from a W3C perspective, how do I ensure something becomes stable - can I base a recommendation on a web component? Publish it for people to use?
... . We need an extension mechanism, and I don't know what the shape is...

MC: Are extensions the long-term solution?

IH: I think they are the long-term solution because we cannot expect browsers to implemnent all these domain-specific things in a browser - having proper mathml and musicml and chemml is a huge amount of work but only scratching the surface
... music publishing is an industry of its own, effectively

RS: Ivan asked how do we work with *-ML. Is this the right starting point? MathML is interesting because tehre are two versions of it. One that everyone uses and a different one that has the semantics many people want.

MC: Ivan made a case for rendering, but web components lack semantics… should we use aria because it feels hacky, … I like MathML for its rich definition.

<Zakim> tidoust, you wanted to mention the layered APIs effort as answer to the "interim" question

MC: isn't it nicer to begin with a rich semantic language.

FD: TAG pointed at web components, mentioned a layered API approach, so you can optionally download a polyfill if you don't have native support for the content you included.

<tidoust> Layered APIs effort

<littledan> +q

<Ralph> Chaals: we might want to taks a step back

<Ralph> ... MathML, MusicML

<Ralph> ... MathML having two flavors was a serious mistake

<Ralph> ... MusicML looks like a poor design

<Ralph> ... how do we teach the people who understand their domain to create a semantic thing that we can work with

<Ralph> ... if we don't do that we might as well paste GIFs and write alt text

<Ralph> ... when we have an idea of how to create these languages so they're useful to work with, taking a well-structured language and building a web component or a polyfill then learning which is best for authoring and which best for rendering ...

<Ralph> ... a key piece is describing the things you need to think about when describing a knowledge domain and putting in in the web

<Ralph> ... our experience from XML is that when everyone could write XML there was a lot of bad XML written

<keith_miller> yes? I'm not sure if that's a question

<Ralph> ... but people to write tools to work with it; render it, transform it, ...

<keith_miller> I'm in the room though

<Ralph> ... we know how to write web components

<Ralph> Ivan: do we?

<Ralph> Ralph: that's a solvable problem

<Ralph> Chaals: we don't have good guidance for people with a knowledge domain and help them XML-ify it

<keith_miller> Ah, ok.

<Ralph> ... give them a sense of what we need from the KD people to hand to web developers to make a nice renderer, a nice authoring tool, programs to manipulate the data for my backend

<Ralph> ... this would be a helpful piece of the puzzle

DC: We have the problem of representation, and the problem of rendering it. Math has shown this is a problem, Houdini is in its infancy at this point. This will create a high bar by requiring people to use Houdini to solve the problems - it's useful for people who write C++ and develop layout engines.

DA: There is ongoing work to reinforce MathML. We maintain the implementations for Safari and Firefox, planning to work on it in Chrome.
... the lesson we get from MathML was that contentMathML was too ambitious, we will work on presentation and acessibility.
... With webcomponents and layered APIs we will get there but it isn't ready yet. But working in browsers directly can give us MathML.
... maybe it is good to have some built in as MathML was…

CL: I think the hard bit is engaging the communities. Engaging meteorologists with geospatial information, we had forecasts and observations, until we realised forecasts were just obs, that were in the future…
... it taook a long time to get to that idea.

[+1 to Chris]

scribe: You have to engage in a long discussion to get those commuities to present their information in a way the web can use it.

<Ralph> [yes, +1 to Chris]

JS: I think we will not get finished - knowledge will continue to grow. I don't think there will be a single solution for a given knowledge domain, people will never be completely happy.
... some people think mathML is great, others think that we need more.
... e.g. even in math there is a whole lot of graphics, … There will always be a corner that needs a new approach. If we figure out the primitives we might start making progress.
... We can find some primitives, which would be a good start we can build on.

<Zakim> Ralph, you wanted to comment on houdini

JS: A small set of stuff might bring in a lot of fields, and get an idea about how to pull this together by practice.

RRS: There are many pieces of this elephant. Having people with different skillsets helps deal with those pieces.
... I take Alex statement that Web Components handles this question very positive.
... our goal is that those who are encoding their knowledge put enough semantics into what we use, rather than mentally transllating their graphic presentation into a format.
... Dave said we aren't sure if Houdini is going to work… I am confident taht given a rich meteorological language, a few people will write a decent renderer or two. The hard problem is to get those who know how to write accessibilty tools that present the content differently to work with those who know how to write a vocabulary, and those who understan the information we are trying to represent, all together.
... Igalia, what more do you need to know from WebAsm and Houdini to know if that will give you a better future for building your tool?

IH: ... In a practical sense I am worried that nobody owns this space. As long as the communities you desccribe, who know how to handle the angle brackets and those who know the acceswsibility tree, seem to guard their secrets like privileged knowledge. That really bothers me.
... This is the part of core webn architecture that isn't just for web core implementors.
... I don't mind the details, but here there is a level of knowledge that should be usable by a larger crowd - giving a description for people who are not highly webskilled of what you need to do...
... I am also concerned by the idea that the floor keeps changing. We need to offer the outside worl more to help them translate their knowledge into what we can work with.

DA: A piece of missing information that I don't think we can answer is whether the layout API has cross-browser consensus. That's a missing piece you need to emulate MathML as a web component. Rendering to SVG loses styling hooks and so on. There are a lot of missing pieces. There is an argument that Web Components should subsume MathML, but I don't think the pieces are clearly in place to make this work yet, e.g. copying and pasting.
... should we repeat musciML?

<dauwhe> https://ishoudinireadyyet.com/

MC: Is Houdini / Web Components supported by epub readers?

RRS: Are we designing for nexgt week, or 2020?

MC: I am happy to design for 2020, but not for 2040.

IH: Today the answer is no, but there is a reasonable ground to believe that they would.

FD: Looking for next steps.

<scribe> ACTION: François to take this on and make it work

FD: There isn't a group who owns this at the moment - it isn't in their scope.
... we need a community. We have an architecture function in W3C who would be a good home for doing this work
... It would be goo to list the technologies mentioned, and start writing the explainers that go all the way down (to the turtle)
... Exchanging and documenting best practices and what is possible.
... We seem to have a green light from teh TAG to go in that direction.

JS: One of the most exciting things I heard is that now math has spent 500 years replicating its work, but the web is a different beast because it is not on paper.

IH: It is extremely difficult to change that.
... in number theory lectures, a professor explained that finding the right symbols and fonts for a mathematical concept was the most important thing to actually deal with problems.

<Ralph> Chaals: what FD said

<Ralph> ... it would be useful to have a group that looks at how to tell communities who want to put stuff on the web what they need to know

<Ralph> ... .examples of patterns that worked and patterns that didn't work

<Ralph> ... across the communities who have done some of that work there will be patterns to follow

<Ralph> ... communities that have been doing their symbols for 20 or 200 years won't change their field quickly

<Ralph> ... but because they want to engage with the web there is some thinking they need to do

<Ralph> ... including authorable content that can be manipulated

<Ralph> ... by mathematicians or musicians in a way that makes sense to them

RRS: Exciting area, accept François' challenge to follow up.

<ChrisLittle> bye and thanks

This is scribe.perl Revision: 1.154  of Date: 2018/09/25 16:35:56  
Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/

Guessing input format: Irssi_ISO8601_Log_Text_Format (score 1.00)

Succeeded: s/DC:/dauwhe:/
Succeeded: s/ACTION/ACTION:/
Present: JaninaSajka MichaelCooper IvanHerman DaveCramer RalphSwick FrançoisDaoust Chaals ChrisLittle BenSmith KeithMiller DanAhrenberg Takeshi EmilLundberg Deepti keith_miller littledan horiuchi tidoust
Found Scribe: chaals
Inferring ScribeNick: chaals

WARNING: No "Topic:" lines found.


WARNING: No meeting chair found!
You should specify the meeting chair like this:
<dbooth> Chair: dbooth


WARNING: No date found!  Assuming today.  (Hint: Specify
the W3C IRC log URL, and the date will be determined from that.)
Or specify the date like this:
<dbooth> Date: 12 Sep 2002

People with action items: fran ois

WARNING: Input appears to use implicit continuation lines.
You may need the "-implicitContinuations" option.


WARNING: No "Topic: ..." lines found!  
Resulting HTML may have an empty (invalid) <ol>...</ol>.

Explanation: "Topic: ..." lines are used to indicate the start of 
new discussion topics or agenda items, such as:
<dbooth> Topic: Review of Amy's report


WARNING: IRC log location not specified!  (You can ignore this 
warning if you do not want the generated minutes to contain 
a link to the original IRC log.)