[wg/pm] Publishing Maintenance Working Group Recharter #481
Comments
|
|
iherman
added
the
Advance Notice Sent
|
hi @iherman, For the security aspect, would it make sense to add the same text you wrote for VCWG for Security maintenance? Thank you |
|
@simoneonofri yes and no 😉... At first glance, the VCWG example is not directly relevant here: once published as Recommendations, class 4 changes for VC documents are not allowed for them (per the WG's decision). The security issues that you refer to is explicitly allowing class 4 changes as exceptions. The PM case is different, because the charter makes the issues around class 4 exceptions moot, because the charter is for a new version of the EPUB specifications, following the "traditional" WD->CR->PR->Rec route. I.e., in theory, such exception is superfluous. That being said, the PM charter is setting the scope expectation very tightly (the publishing industry is very averse to change, hence the precaution). As a consequence, it might indeed be a good idea to add an entry to, e.g., the second bullet list in the scope section which makes explicit some incubation work that may or may not end up as part of the Recommendation in this charter round. The item would reuse the same text:
(Note that I have added privacy, because I actually think it has the same issue.) If you agree, I will raise a new PR soon, but I would prefer to do that if and when w3c/publ-maintenance-wg-charter#44 is merged, because that PR makes a more serious re-write of the scope section and I do not want to create a github merge mess... |
|
@iherman thank you for the explanation, approved the PR |
|
no comment or request from i18n |
|
Looks fine from a privacy perspective. I don't know that the maintenance group can address all the privacy-relevant issues with ePubs, but horizontal review as normal seems fine and the charter does call out security and privacy fixes as within scope. |
|
APA is OK with this charter. |
|
For the record the PR mentioned in #481 (comment) has been raised and merged. |
|
From EPUB 3.3 1.3.3 Relationship to CSS:
It would therefore seem wise to include CSS WG in Coordination W3C Groups. (I understand that the prefixed properties are no longer maintained, and are deprecated in new content, so feel free to push back on this, if that is the reason) |
Like you said: prefixed CSS properties are considered a leftover from the past. See Appendix E which explicitly says:
Ie, I do not think there is a need for another liaison. cc @mattgarrish, just to be sure... |
|
Ya, the prefixed properties aren't quite deprecated but aren't recommended for use anymore. I haven't heard anyone express any new needs for CSS that we would require a liaison for. |
|
Given the shift in the first sentence of the scope section: Does it still make sense to call it "Publishing Maintenance Working Group" ? Or should we simply rename the group as "Publishing Working Group" ? |
I considered that, but I was worried about bike shedding. The name "Publishing WG" was used for the Working Group that defined the Publication Manifest and the Audiobook spec, then was renamed as "Audiobook WG". We deliberately named the next group "EPUB WG" to send the message on working exclusively on EPUB and not on something radically different. So renaming this group as "Publishing WG" would be misleading and could send the wrong message to the community. The alternative would be to come up with a new name again. The group's charter, two years ago, was to maintain everything in one place, hence the current name. Actually, the WG continues "maintenance" on the Audiobook and Publishing Manifest specification although, I admit, the focus is now on EPUB. But the name is not 100% wrong. So far nobody really raised this as a problem and, as I said, bike shedding the name does not look like an energy worth spending... |
|
In the list of deliverables, it's a bit surprising to read "EPUB 3.3" (BTW there's a typo, s/EBUB/EPUB) |
You are absolutely right, @caribouW3, my bad. I have changed the text. |
|
Is this an issue that must be decided right now, or is it o.k. to discuss it with the WG during the AC voting stage? I must admit that I am very uneasy to start such a bikeshedding right now, because it will lead to a long delay.
I leave this issue to the maintainers of the template... As an editor of the charter text, I am not supposed to deviate...
Yes, this feature is one of those implicitly referred to in the scope section: "Work with the Publishing CG's accessibility task force to incorporate incubated features". We could add the document as an example to that statement. cc @mattgarrish
Oops, sorry, there were indeed two more. I have taken care of them. |
Both @dontcallmedom and myself indicated that this was a non-blocking issue, so it's up to you. It certainly fine to move forward as-is and figure this out during the AC Review. |
It's now in w3c/charter-drafts#627 |
My personal take: I'm not sure it needs such a long delay, but if it does, I don't see how waiting for the AC review would help; and in terms of not underselling the change of the scope of the charter, the AC is a primary audience, so it would feel much more logical to settle it beforehand. I assume switching to "Publishing Working Group" has dragons I'm not aware of? But again, up to the group to assess.
For sake of clarity: if it is indeed meant to be incorporated in the EPUB Accessibility specification, it shouldn't be listed as a non-normative deliverable (but may be worth mentioning explicitly in the description of that spec in the normative deliverables list). |
I don't think we envisioned it becoming a direct part of the accessibility specification. Detailing a property that tells users how to exempt themselves from accessibility requirements, even if that's what their local laws allow, is kind of contradictory to the spirit of accessible publishing. It could be its own normative document, of course, with maybe only a note in the accessibility specification's conformance section pointing to it. |
See #481 (comment) |
This alternative was not raised by the WG's review of the charter. Hence it is where it is... |
Right, sorry, to be clear, I'm not suggesting that's what we need or want to do in this revision. I was just responding to whether it could be its own normative document. I think the group is fine keeping it in its current state. |
|
I think it's confusing (from a conformance, IPR perspective) for the broader community to have documents with normative requirements published by a Working Group as a Note - what is the rationale for not having it as normative document? |
|
From #481 (comment)
My (personal) reaction is to maybe 'weaken' the note's language to make it clear that this is not a standard... But I rely on the opinion of @avneeshsingh @mattgarrish on this issue. |
|
Apart of the spirit of accessibility, there is a practical reason to avoid Rec for this property. It is influenced by EAA, and will be influenced by Title 2 and legislations in other countries. Rec is a pretty heavy mechanism for maintaining such a document. |
|
The property was also created for parity with onix records that publishers provide to vendors. We try to make sure that publishers can express the same information within the epub package document as they provide in onix, and vice versa. The metadata isn't critical to the accessibility specification nor to rendering epub's generally. It's information that may only ever travel between the publisher and vendor. It could be defined on REC track, but I don't know how much more helpful that would be as @avneeshsingh has said. I'm good with @iherman's suggestion to remove the normative keywords and keep the document fully informative, which we could do immediately. |
Thanks for the explanations. That seems fine to me. |
|
@mattgarrish @avneeshsingh moving towards making the Note looks less normative actually goes against my suggestion, and my perception of what the document represents: I don't understand what it means to define a non-normative property (it would seem to imply anyone can use it for whatever purposes they want); it's all the more confusing that the said property is defined as part of the official W3C-controlled a11y epub namespace, and comes with a limited number of acceptable values. That the property is in addition meant to respond to a regulatory context further strengthens the value of making it a normative document, with the proper review process. If @avneeshsingh 's concern about the Rec-track is linked to the need to add more values over time for the property (e.g. to match new regulatory requirements), this to me points toward a combination of a simple short Rec-track document (defining the property) and a Registry-track document (defining the possible values). |
"Publishing Working Group" feels less misleading to me than "Publishing Maintenance Working Group" given the expanded scope; there may be better options ("ebook publishing WG"?), but using the term "maintenance" in the name feels to me like it would send an even more wrong message :) |
|
I am sorry, I have to disagree. The publishing community is very keen on keeping backward compatibility and, at the moment, not moving away from EPUB. We have made the mistake, under the heading of the Publishing Working Group, to engage into a line of work which the publishing community did not really pick up for a lack of a clear business case. It was a very conscientious decision, a few years ago, to go for an EPUB Working Group (and rename the Publishing Working Group to Audiobook WG, which was the only area where a business case was indeed there). Moving an EPUB work "back" into a group called Publishing Working Group would send a misunderstandable, and potentially negative, message. So yes, as you said, there are dragons. I would not be against a different name, but I would not want to use the term "Publishing Working Group". But that would require... bike shedding. |
In publishing area, we already have many EPUB files and we will not want to pay huge costs to modify them by adding new normative restrictions in the new version. EPUB uses Web technologies but it's distributed as a package, which means that it's not easy to modify exsisting EPUB files rather than Web pages. So we have to pay attention to a backword compatibility. |
It's bikeshedding if it means spending time on non-consequential matters; given the history you describe, it does feel like it is consequential :) (and the fact that the current naming proposal is still a derivative of "Publishing" for a new version of EPUB strengthen the value of finding a different name) |
AFAICT, making the document normative doesn't entail requiring using it or invalidating previous packages. e.g. it could say "Authors MAY use a11y:exemption to indicate a legal exemption; if they do, they MUST use one of the values defined in the registry. For sake of clarity, in the context of the charter discussion, my point is that the charter should not have this as a non-normative deliverable (since that could be read as forbidding it to be normative); if my point regarding normative-ness is worth considering, but the discussion about whether to make it normative or not cannot be settled rapidly, it could be listed in the normative deliverable list with an indication that it may end up being non-normative (from an IPR perspective, it's easy to switch from normative to non-normative; the reverse isn't) |
|
I agree with Dom about not using the term "maintenance" in the name of the WG. The fact that we used to have a different WG that produced different deliverables feels somewhat irrelevant. We are mostly the same people working on the same things, but this work is a direct output of PMWG, and changing email lists etc will be disruptive. I don't really care what we call it as long as the work isn't disrupted. |
|
Would it be possible to document |
|
The property only exists for metadata parity with another vocabulary, so putting it on REC track in W3C seems inappropriate. I don't know that this group would even be the appropriate place to go about standardizing a reporting property for all of EAA, as the EAA itself doesn't require this that I'm aware of. What signal are we sending if we do try to standardize the property? It's an informative means of exchanging information. Actual reporting is carried out through other authorities. Given that, I think it's safer to leave it informative, remove the normative requirements, and wait to see how things evolve in this area. You can add lots of metadata to epubs that isn't normatively defined, so I don't see that being a problem in itself. |
I disagree that using the word 'Maintenance' excludes an expanded scope (especially given the hard requirements for backwards compatibility). To 'maintain' something (keep in an appropriate condition, operation, or force; keep unimpaired) perfectly describes what this group does, and what we want to do going forward.. |
|
Can we call it the Publishing Business Community Working Group just to confuse everyone? 😉 I liked the old publishing working group name, but at this point stability wins out for me over changing names yet again. As @TzviyaSiegman says, it's disruptive to keep changing group names every couple of years. |
|
The name of the Working Group may stay as "Publishing Maintenance Working Group" and is not considered a charter issue. Here is our understanding of the situation of the
While the Publishing Maintenance Working Group is concerned about the prospect of publishing a Recommendation that allows to bypass accessibility requirements, we believe the EPUB Accessibility exemption property ought to be listed as deliverable or part of another deliverable on the Recommendation Track. The adjusted proposed charter would then be submitted for AC Review. @dontcallmedom and I are happy to further discuss the issue as needed. |
|
@iherman is looking at organizing the discussion. |
|
Conclusion: the exemption may be included into epub-a11y in the future but there is still more thinking to be done around it. The best way forward is to keep iterating within the CG /WG and not constraint the WG one way or the other for now. To do that, best way is to remove the Note from the non-deliverable section and add a bullet about it in the section about incubation. Since the property falls within the scope of the Working Group, if the conclusion is to add it into the epub-a11y deliverable, this could done without a new charter. |
The document did get a review from APA. |
New charter proposal, reviewers please take note.
Charter Review
What kind of charter is this?
Existing WG recharter
If this is a charter extension or revision, any issue discussion:
Communities suggested for outreach
(Digital) publishing in general, including
Known or potential areas of concern
The main concern is to have clear backing from publishers (we have many of the Reading System providers on board, like Apple, Google, Kobo/Rakuten, or EDRLab)
Where would charter proponents like to see issues raised?
Anything else we should think about as we review?
Under the current Working Group charter (expiring in June '25) the Group is not authorized to publish new versions of the Recommendation with class 4 changes. The objective of the new charter is to explicitly list features that were discussed/incubated in the Publishing Maintenance Working Group or elsewhere, and which are ready to be added to EPUB as
standard features following the standard Recommendation process.
There are no plans to fundamentally change EPUB 3.
cc: @shiestyle, @wareid, @rickj, @swickr, @BillKasdorf
The text was updated successfully, but these errors were encountered: