<Julian_Calderazi> I'll be on IRC the first 10-15min.
<Julian_Calderazi> and refining dc:subject and running epubcheck 4.2 alpha too.
<dauwhe> anyone wanna scribe?
<dauwhe> I can hear tzviya
<larscwallin> Hello :)
<scribe> scribenick: Rachel
larscwallin: Lars from the
reading system Collibrio
... we will release 1.0, our first public version, at the end
of this month
... we encourage people to try to break the system
<dauwhe> https://github.com/w3c/publ-epub-revision/issues/1194
dauwhe: manifest.xml naming requires googling because it's purpose is unclear
<larscwallin> Nope
dauwhe: I proposed a note
<Julian_Calderazi> no. +1 for adding a note
+1
<Naomi> +1
dauwhe: OCF allows epubs to be
digitally signed but it's not clear if reading systems have to
support this and what happens if the signiture is
invalid.
... we seem to have concensus that the reading system is not
obligated to support signatures
<Julian_Calderazi> Sorry @dauwhe should an invalid signature be understood as an error?
dauwhe: what does the RS do when the invalid signature is invalid?
<larscwallin> The reading system should warn the user
dauwhe: we don't require reading systems to do much - could we require them to alert the user
<Julian_Calderazi> (yes sorry. no audio for the next 5').
<Julian_Calderazi> or a Warning.
Naomi: if the reading system supports signatures and it is invalid then it should say the signature cannot be found
<wolfgang> could not a signature be also technically invalid, because its certificate has run out?
CharlesL: when digital sigs didn't match at benetech we put up a bold warning that that sig didn't match and content may be corrupted
dauwhe: so, should alert the user
larscwallin: if we're talking about supporting packaging in the future, it would be strange not to notify the user of an invalid signature
mattg: If we're going to spell
out reading system obligations it may start to get confusing
about whether we're using the right terminology
... the processor doesn't have to be a RS so we should be
careful about how we word these
lars: then it's even more important that we have strong language in the documentation regarding invalid signatures
dauwhe: So as a new proposal:
<larscwallin> It needs to continue to parse
<larscwallin> But report to the user
dauwhe: I will think about potential ways to describe this
<dauwhe> https://github.com/w3c/publ-epub-revision/issues/1200
dauwhe: we don't really define
what this means
... what does it mean for an OCF processor to treat something
as an error
... we have a series of statements that are untestable
... some of these errors make it impossible for the OCF
processor to continue processing
<Julian_Calderazi> I agree with Garth Conboy comment (14 days ago). Yes, No
larscwallin: would it be possible
to have labels for errors or exceptions that can be
supported
... we could define how they could be more explicit in their
error reporting
tzviya: one of brady's comments
was that he's not sure if OCF is verifying in the real
world
... If not sure what the extent of these errors are
... if there's an error encountered, can the epub still
function
... if it can, we don't need to do anything else
... if it can't, we need something akin to http error codes
mattg: I agree with tzviya. The only thing I would add is that we have RS conformance requirements at the top of the spec, there's an opportunity there...
zheng_xu: this is similar to when we have a website with js error, the potential error is more useful for a developer or epub creator not a reader or user
<larscwallin> With the exception where the user is another piece of software
zheng_xu: in the spec I saw the ocf errors about zip and compression. As a reading system, we work within the limits of the library we're using.
duga: "Oh hell no" to the reading system displaying error to the user
<larscwallin> I do not think this is what anybody meant though ;)
dauwhe: so a reading system can do what it wants more or less...
duga: usually what the user wants is for the RS is to do the best it possibly can
wendyreid: I agree with duga but
there are merits to the errors. On the RS side, we should do
the best we have with what we have. Kobo does a lot of
validation on the backend.
... if there are serious errors, we have ways to fix that
... if the error blocks display and we can't fix that - then we
try to warn the user
larscwallin: it would reduce ambiguities if the standards were more specific about these things. I don't want to show human users confusing messages but you need to be able to catch the issues and define them explicitly to resolve them quickly and early
zheng_xu: sometimes the issue is so severe that you need to stop processing and notify the user that the product is unavailable
Avneesh: I fear this would be
information overload for the user
... this also brings us closer to reading system guidelines
which leads to the question, is 3.2 the right place to discuss
this
<larscwallin> Thoughts are a dish served hot ;)
dauwhe: I will revisit based on today's comments
<zheng_xu> s/ zheng_xu I'm so sorry - the sound cut out for a significant portion of that, please edit at will/OCF error should be handled by OCF processor rather than reading system. Reading system's mission is to display book as much as it can to reader/
<larscwallin> +1 for forbidding
dauwhe: do we explicitly forbid resources from inside the package being in meta-inf and ask epubcheck to enforce that
<Julian_Calderazi> @dauwhe if approved epubcheck, should this be filed as a bug too?
garth: I'm torn... I'm sure it would be fine in our RS. There's prob very little instance of it (or any?) So maybe it's a should not?
larscwallin: what we discussed
before was the responsibility of the OCF to the reading system.
I think here we need to forbid non-metadata from going into the
meta-inf. It should result in an error and fail
gracefully.
... this is why we need exception handling
<wendyreid> +1
garth: I don't have any objection to epubcheck throwing an error but I would object to a reading system not being allowed to white list it
romain: [silence]
... [more silence]
... [silence speaking volumes]
larscwallin: if we were more explicit about what is forbidden, we would be less reliant on epubcheck
<romain> I'm not so much worried about Content Docs being in META-iNF, more about proprietary metadata files, legit in META-INF, that would become rejected in EPUBCheck
<larscwallin> Not really, it is more of a design thing
mattg: isn't the real concern the theoretical concern that someday we might want to define something in there that creates a conflict?
dauwhe: there seems to be consensus that content in meta-inf is bad. maybe I'll file that and see what comes up.
Naomi: I think those apple files would fall under configuration files and now that we have epub3 they're less necessary. We need them for bastardized epub2
wendyreid: you're right but we are still seeing them in epub3
<romain> what EPUBCheck could do is check that core media types are not in META-INF? would that be a reasonable intermediary option?
<romain> (in that cas the spec would need to be updated too of course)
tzviya: romain are you familiar
with anyone that sneaks anything into meta-inf?
... we need to update the spec in ways that we don't create
issues for validation
dauwhe: okay, let's tentatively explore this
dauwhe: I think mattg says yes?
<romain> it sort of feel weird to accept as a "valid" fallback something that we know is _not_ implemented
Naomi: we don't use it
<romain> but I agree with Matt that this falls into the realm of best practice…
garth: we don't support it
larscwallin: we will at some point need some kind of web component support. The binding concept seemed kind of ahead of it's time when we started using angular to start.
<garth> Is deprecated in 3.2
dauwhe: we'd like to deprecate
lars: replacement?
dauwhe: we'd like to do something with web components eventually, but right now we're trying to focus on getting rid of weird non-web stuff that epub did.
garth: it is deprecated in 3.2... I can't see it coming back. If we get to a different answer on backward compatibility we should consider removing these elements
dauwhe: so any objections to the
proposal?
... no?
... then it shall be so
<larscwallin> Sorry for taking up to much time on this topic
dauwhe: svg 1.1 or svg 2?
<larscwallin> SVG2 is perhaps a bit early. It is not really supported anywhere right?
<Julian_Calderazi> Makoto is right. v1.1 is the latest (now, today)
<larscwallin> Except perhaps in Edge (for a while longer)
mattg: [speaks using a lot of acronyms that Rachel misses]... should we reference the latest stable version?
<larscwallin> Up to date with the web is 1.1 now I would say
dauwhe: we need to align with the web, not the landmarks of the w3c process. The CR often aligns with the state of the web
tzviya: the def of final rec is
evolving in the w3c
... the living standard might make it necessary for us to make
this decision on as needed basis
Avneesh: we need to consider the impact of where we point on ISO
<larscwallin> Thanks everyone!
<dauwhe> RRSAgent: draft minutes
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/invaid/invalid/ Succeeded: s/we seems/we seem/ Succeeded: s/encounterd/encountered/ Succeeded: s/conformence/conformance/ Succeeded: s/what the user whats/what the user wants/ Succeeded: s/porcessing/processing/ FAILED: s/ zheng_xu I'm so sorry - the sound cut out for a significant portion of that, please edit at will/OCF error should be handled by OCF processor rather than reading system. Reading system's mission is to display book as much as it can to reader/ Succeeded: s/THere/There/ Succeeded: s/properietary/proprietary/ Succeeded: s/are/are you/ Present: wendyreid wolfgang dkaplan3 Julian_Calderazi tzviya dauwhe Rachel romain Avneesh zheng_xu Naomi mattg CharlesL Garth liam duga Regrets: Evan_Owens George_Kersher Luc_Audrian Jeff_Buehler Found ScribeNick: Rachel Inferring Scribes: Rachel WARNING: Could not parse date. Unknown month name "01": 2019-01-17 Format should be like "Date: 31 Jan 2004" 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: 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.)[End of scribe.perl diagnostic output]