See also: IRC log
<tzviya> welcome Peter!
dkaplan introduced herself. With Safari books, accessibility expert; both standards, QA, coding side well versed.
liza: approving last week's minutes
liza: minutes approved.liza: main topic: structural semantics
markup group.
... table at end, proposing various options for annotating structural
semantics.
... need something more friendly to OWP.
<tzviya> https://www.w3.org/dpub/IG/wiki/StructuralSemantics
<ivan> Table on the criteria
liza: wiki was updated.
Ivan: summarizing: tried to put something
for each table.
... AT contract not always clear.
... my opinion. could be totally wrong.
... dauwhe comments by email.
tzviya: goal: spelling out _very clearly_
why we want / not want to use these.
... ex. namespacing.
Ivan: let's go through it line by line.
... everybody can respond.
... namespacing -- current approach in epub.
... primary issue: XML specific thing.
... future is HTML5 w/o x
... then namespaces are the either a problem or produce dissent.
... if HTML5+scripting is the future, then XML namespaces dangerous.
liza: anyone think moving away from namespaces is a bad choice?
davidCramer: what is IDPF's position?
mgylling: IDPF is currently doing nothing.
... wants this idea to produce recommendations to inform IDPF.
... namespaces have lots of problems + workaround to avoid/deal with
namespaces.
... wait for recommendations from W3C and DPIG
... integrate in epub / IDPF standards.
... re first column: AT contract might be a bad choice
... more whether AT digestion is automatic.
... whether existing solutions can deal with it
... whether existing APIs can already provide.
Ivan: JS developer today will use one of the
major libraries (jquery etc)
... those tools usually don't test for xhtml anymore.
... risk that future development will tend to not work on xhtml.
liam: robin's comment at Paris workshop
explicitly do not apply to xhtml.
... if you add namespaces, you're going outside polyglot spec
... don't see Robin's argument as abandoning xhtml.
Liza: but still true that libraries won't support xhtml.
liam: true.
frederick: about the table. what functionality are we looking for?
mgylling: this is not about serialization.
(we might want to discuss this some time)
... it's about semantic inflection.
... we need to do this serialization agnostic.
... don't want to use HTML-specific or xHTML-specific ones.
liza: so third column most important.
Ivan: on to next line in the table: @hyphen
... ppl using `ebook-type`
... existing mechanism
possible to add such attributes, serialization agnostic,
<mgylling> clear AT contract, no: +1
Ivan: static provisioning.
... much like epub right now, just slightly different string.
... one key problem: validators. Any value would need approval HTML5 WG.
Ivan: needs kind of registration-process.
... HTML5WG would look at values "what values are useful in general?"
... would slow down the process.
liza: how would that be serialized in xhtml?
ivan: same attribute names.
liam: as soon as you add your own, then
you're going outside the comfortable zone.
... data-* is the natural way.
Ivan: I don't think it's the same issue.
... yes, data-* more natural.
... but @hyphen defined that you can get to these attributes (via JS)
just like any other attributes.
... will be in the DOM, JS can access them through regular DOM calls.
mgylling: ITS 2.0 attributes are an example.
Luc: wondeirng about openeness.
<tzviya> See http://www.w3.org/TR/its20/ for reference
Luc: with @hyphen we have to get through
validation.
... if we put any kind of vocal inside them.
Ivan: there should be recognized body that
defines the possible values.
... ex. IDPF could be that body; shouldn't be a problem
Luc: namespace problem is moved to attributes.
Ivan: yes. but agnostic to serialization.
... next in table: RDa / MD
Ivan: the problems: no clear AT contract
... problems: for many considered too complicated for users.
... for authors, conceptually.
... MD more hidden
... problems: appropriateness.
... RDFa sensitive to subject.
... (see last column)
... e.g. concert. MD is about the concert, not the div element holding
the description.
<mgylling> +1
Ivan: I think the goal of this table is something else.
Bill: want to emph. that last point.
... make that distinction strongly.
Luc: but I think we need both.
... describe document and describe what it's about.
Ivan: completely agree.
Bill: agree.
Ivan: only: this table here is not about
that.
... this is about marking up index etc.
Bill_K: maybe call it "structural refinement"?
Luc: that makes more sense.
DaveC: is that problem that HTML is not granular enough?
Ivan: agree.
<fjh> +1
<Luc> +q
+1
Luc: understand distinction.
... but we could use RDFa appropriately.
... why couldn't RDFa not be used to describe the doc itself?
<mgylling> If Luc is right, why did the ITS2.0 folks not go this route?
Ivan: technically it could be done. But very
technical. You need to give a URI to each DIV element on which you make
a statement.
... horrendously ugly and complicated
<mgylling> answer: “horrendously ugly”
Ivan: thats' why IDPF didn't adopt it
either.
... @role. much like @hyphen
... but we get into a similar problem.
... how would the values be registered.
... there's role and sometimes aria-* attributes.
... biggest problem imho: registration needed.
... would have to go to a11y groups.
<mgylling> +1
Ivan: while this is partly a a11y technology, it's not directly.
mgylling: @role: we had some discussions
with PF people (Rich Schwerdtfeger).
... PF thinking about going beyond AT with @role.
... but no guarantee that they will go there.
... we need an update on that .
... but: only one to get +1 on AT column.
... no need for specialization from AT tech.
... @role is unique in that.
Liza: only advantage over @hyphen?
mgylling: no need to create specification.
... easy to get support from validators.
... maybe.
Ivan: maybe indeed.
... we'd have to deal with 2 WGs if we go down that route.
BillK: any issues of multiplicity of attribute?
Ivan: I don't know.
BillK: multiple values for @role attribute (aria + publisher specifics) is that a problem.
mgylling: no, it already takes care of that.
... in theory anyway.
<tzviya> https://www.w3.org/dpub/IG/wiki/Summary_of_20140314_Structural_Semantics_Call
tzviya: a) meeting with Rich. leaning
towards @role rather than new spec. => link.
... personally +1, easier to implement.
... would have to look at the inherit semantics.
... can't be introducing contradictions.
Ivan: we need (urgently) update from PF working group.
<Zakim> Bert, you wanted to ask why there are no external formats in the table, e.g., <link rel=glossary href="terms.glossml"> or linked from a manifest file.
liza: let's skip @class and @data-*. They're
both for different things.
... custom elements?
... tackle now?
Ivan: is it a sledge hammer?
Ivan: means: we add a new HTML element.
(thanks liza)
Ivan: justified for some things (ebooks in
general yes)
... but for this particular problem, it's nuking the problem.
mgylling: put it in because it's hailed in some pub tech as the best thing since sliced bread.
<liza> dauwhe: Ha ha
Ivan: heard it at Edupub, for widgets.
... great topic in general for the IG.
... just not here.
<Bill_Kasdorf> +1
<Luc> +1
tzviya: even if we propose "chapter", it would bring up a huge list of elements, most of which would be hard to communicate.
<Bill_Kasdorf> +1
mgylling: has utility for books, but for more complicated ones than this one.
+1
Bert: all of these are in the document
itself. Why not external format?
... e.g. an XML document to point into the document.
I'm not follwing b/c markus has too much background.
Dave Cramer: if we add vocabularies, it
would be overkill to link to an external file.
... saying this is a chapter.
mgylling: some other ideas for CSS to go beyond styling.
Bert: old idea. Ever since RDFa, CSS has been saying: that's just what CSS does.
Ivan: technically I can see something like
CSS selector used for that; relatively simple.
... but still needs some hooks into the HTML text itself.
... no real win
Bert: maybe not all use cases. But some things, like glossary.