Digital Publishing Interest Group Teleconference

<trackbot> Date: 19 May 2014

<ivan> Minutes of last week

Next monday's meeting is cancelled. week after that is tentatively for Dave Cramer to talk about GCPM module within CSS and status update and next steps for LATIN REQ document

structural semantics

scribe: Two topics: we didn't finish discussion on structural semantics so will spend some time on it today and look at next steps with various stake holder groups. After that, we'll talk about STEM task force and setup a plan to build a corpus of use cases around science and math

<mgylling> https://www.w3.org/dpub/IG/wiki/StructuralSemantics

scribe: Gerardo has appended a bit to the use case collection esp in SVG and infographics area. Let's edit use cases and complete them more. Don't need to do that here as that's editorial stuff. But we shouldn't forget about the use cases before we start talking about solutions. Remind everyone to read through them

pkra: Just added some uses cases for STEM to the wiki
... Added 2 use cases to enhance user agent behavior-domain-specific fragments, in math mght have theorems and proofs, might be reused but only in reference...
... leveraging annotation xml in mathml which is used to provide semantically rich...these pop up in the content repurping section...formula chem. equations...not thinking of 3d representations, these will often use presentation mathml but there is some semantics for chemistry
... content mathml is often used to represent math. in computational environments, making it available for reuse is a good use case

mgylling: these are all in terms of user-agent behavior or reprocessing behavior

pkra: they also touch accessibility
... didn't know how to incorporate the use cases into table bc does not require new solution..

mgylling: does what peter is talking about count as structural semantics? annotation xml already has a solution. we might move a few to another page as housekeeping

ivan: i dont know whether the various options we discussed like the role or hyphen attribute - is it without a problem to use it inside the mathml element?
... in a way even if we didn't say it explicitly, all the solutions we have in the table we concentrated on html, and want to be sure none of the solutions would create a problem in mathml or svg

mgylling: there are svg uses cases here. the role attribute is making its way into svg 2.0. it's true that for SVG it's very much needed.

ivan: and what about mathml?

mgylling: if you look at peter's domain specific content fragments up in enabling enhacned user agent behaviors, where user would adapt level of detail by nature of the references depends on wheter it's exposed during the reading

pkra: that's the one case that doesn't touch mathml directly, you are looking at microdata or other markup that would provide semantic structure

mgylling: in terms of inlining inside mathml, is there anyone else who has been doing anything?

ivan: bert, is it illegal to use the role attribute within mathml?

Bert: good question

ivan: or is it allowed to use ebook dash- something in mathml?

pkra: it should yes because it's xml. if annotation element had speech text would need to expose that
... the way mathml is integrated into html5, it should work, html tags are allowed to mix within mathml tags so it should be valid. i will reach out to math group

tzviya: we're talking about 2 diff issues. peter's use case about domain-specific content frag is not specific to math, could apply to any kind of book. the other issues we might be able to think about if this is specific to this category(???) o if this is a mathml issue

Bill_Kasdorf: wasn't ivan's question, as we zero in on these mechanisms, make sure we don't do anything in conflict with mathml

ivan: yes that was my concern

pkra: i was browsing the mathml spec. i think @role is fine within mathml

<pkra> http://www.w3.org/Math/draft-spec/chapter5.html#mixing.annotation.keys

gcapiel: i worked with Rich and i think role is totally fine. is it specific to SVG 2, not sure

mgylling: move to the table
... first of all, during last week's call, tzviya made all the updates yes?

tzviya: yes

mgylling: anything we didn't spend enough time on last week?
... looks like we got through the whole thing last week. that's good. to repeat, we're doing this exercise so that ???will publish a recommendation on how to handle this in the future. doesnt mean everyone has to follow it slavishly but it will make it easier for common uses cases
... we need to hone in on one. from last week's discussion it would appear that the two options that are closest to being a good choice are the role attribute and the hyphen space attribute, row 2 and row 3 from the end. they meet most of the criteria, custom elements meet a lot for them as well except for scripting
... tentativelt we look it as a sledgehammer solution to a simple problem.

<ivan> +1

<tzviya> +1

mgylling: my suggestion is make an agreement on what solutions to focus on going forward. the role attribute and they hypen attributes are the two best options and we should focus on them going forward. what do people think?

<liza> I care

mgylling: do you think i'm right or does no one care?

<david_stroup> agree with markus

<david_stroup> agree with markus

Luc: can the role and hyphen attributes be as general a s possible? can i use them to put ANY structure, any semantic structure,?

mgylling: shouldn't be constrained by the spec and should be able to use the vocab you want. if a hyphen attribute is defined, the definer can make up the rules and it can be as locked down or as sextensible as we want. as to the role attribute, we'll have to discuss with the ARIA PF (?) working group
... no one has forgotten extensibility

Bill_Kasdorf: strikes me that discussion with ARIA is urgent unless consensus is hyphen attribute

mgylling: we should contact the PF working group and start discussions with them. one of the next working items to talk with Rich Schwerdtfeger and by him the PF working group. Action item for me.
... need to know how vocabs would be maintained and so on

Bert: are you saying a single solution would apply to all use cases?

mgylling: we prob. want to move the mathml use cases from this wiki page since they have a solution already (annotation xml). i was talking about the use cases before the mathml use cases was added.

Bert: indexes don't need anything new

ivan: why?

Bert: i would do index it with class and dfn element, so no new elements or attributes are necessary. maybe glossary we do need something new.
... the different use cases may not all use the same solutions

mgylling: so did you say the html spec definrs a class attriburte for index?

Bert: no, but i've been using class att for years. don't need to define a dash attribute. for index that should be fine, perhaps not for glossary but that's a diff use case

mgylling: so you are sugg. we use the class attribute. we recommend against it, and you disagree?

Bert: for that use case, yes, but not for the other use cases

Bill_Kasdorf: could you explain the distinction that makes class permissable for index but not glossary?

Bert: for index, it's small thing, not much to do. use class/microformat.

Bill_Kasdorf: asking because epub indexing spec is much more complex than that

<Luc> EPUB Index 1.0 uses epub:type!

<mgylling> http://www.idpf.org/epub/idx/

Bert: well maybe we should have discussion sometime because i doubt it's that complex

mgylling: biblical diff in ambition here

Luc: if we move to role attributes we will lose what we are doing with epub type?

mgylling: that's idpf problem not our problem. if idpf decides to move away from epub type there would be a period of transition and pain. idpf has not made up its mind yet. their prob, not this group's

Luc: would have to move to general html5 solution if we choose to ex...semantic picture with role attributes

ivan: several things, many attribute values used w/ epubtypes are useful outside the book world. if we go with something that replaces epub type, that means we provide a number of attribute values..that users might pick up not only for books
... actually this is also back to Bert's comment: i believe that there are cases where current solutions do work.

ivan: want a general mech. that are close to one another that authors could use easily, that's what this table is trying to do
... goal is to make it easy and obvious and have unified mechanism

tzviya: going back to what Bert said: if there is an easy html solution I'd love to see it

Bert: if i may clarify, I'm talking about a specific use case. don't need to specify any format for the index at all for the spec. use cases

tzviya: we tried to be somewhat broad, perhaps we should be specific. there are more use cases that we could include.

mgylling: maybe we s/look at the index one again and see if we need to spice it up a bit?

tzviya: sure

Luc: th vocab of epubtypes is used outside the book world. all the vocabs we can find in the semantic web are very useful
... a book can be divided into books, sections, but different chapters ...geographical meaning...not a chapter but a town or region...would be useful for ARIA, for question of accessibility

mgylling: are you talking about RDFa
... why dont we want to use RDFa for this kind of stuff?

Luc: in the table in the wiki we decided not use RDFa.
... you did not provide RDFa as an option

ivan: point is we voted against RDFa for the use cases that we are describing here. i would not vote RDFa out altogether. when we are talking about semantics that are ...RDFa is the natural way of doing it. Ebooks today put in meta statements all those can be done in RDFa. but when we ask which ones is a chapter or section, that's a diff. use case.

mgylling: close discussion for now. action item: i will reach out to see if the this is an option for us.

STEM Task Force

mgylling: And now to STEM
... Peter you worked with Jean Kaplansky. did you discuss scope or primary areas you want to work on?

pkra: no. open to suggestions
... also interested in who might be interested in who might want to work with me?

mgylling: this kind of content challenges pub. the most today. it is one of the most acutely in need areas for pub. right now if you include accessibility. so i think one good strategy is to start and build up a collection of use cases
... to get peple to join and help out moving forward.
... objective is to identify areas where open web platform does not meed the needs of dig publishing. what we wan to encode is where all these scenarios are.
tzviya: chemistry is often captured images, sometimes captured mathml. math is a little bit different. a lot of the challenge you face is browser support
... that's one of the issues here. I don't really see what we can do to improve browser support

ivan: we already had a case with fonts where we came to conclusion already...no there is nothing missing, there may be practical implementation issues, but not specification issues.
... i dont know if that's the case for mathml...maybe it's perfect and all issues are solved? STEM is not only mathml. there are a number of issues that do come up in STEM
... it's a little bit the education world. maybe other issues like interactivity, needed in STEM, math or no. where pub do hit spec issues.
... does SVG fulfill those requirements?
... is canvas acceptable for publishers

pkra i agree with that

pkra: STEM side there are limitations. if anyone has good expertise there, it would be much appreciated

Gerardo what is status of talks with Metrodigi or Inkling?

ivan: had some good conversation in salt lake

Bill_Kasdorf: versioning and authentication. that field lives and dies by a published paper being valid or not. it provides a mech. to let them know if they are using the latest version...

tzviya: i can talk to my colleagues at Wiley Online, cross-referencing, we live and die by DOI as well
... when you are doing open heart surgery it has to be the right guide

<liza> Hopefully no one consulting that guide during said surgery

ivan: this opens up a huge area and I don't know if it's not too huge for us. dont know if it's too big for us. would love to get there but that opens a whole lot of issues.
... I don't know if we have the expertise here to handle that.
... many of probs that relate to books relate to journal publishing

<pkra> +1 -- works for me.

mgylling: for peter, consolidate a new wiki page with STEM use cases. You focus on yr area of expertise first--stuff surrounding math. take what you and jean added earlier, prune the other stuff....
... structural sem subclassing of elements, and lift that over to yr new page. that would be step 1. does that work?

pkra: yes

mgylling: talk again in 2 weeks next week's meeting is cancelled