Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Added an editors' draft for the separate Structural Semantics Vocabulary WG Note #1847

Merged
merged 5 commits into from
Oct 14, 2021

Conversation

iherman
Copy link
Member

@iherman iherman commented Oct 12, 2021

Following WG Resolution.

Few practical notes:

  • In order to make a reference to the new document, and avoid invalid links that might create problems in the publication process, I have

    • Added a temporary entry to biblio.js
    • Used, for referenced values, the github.io URL for the document

    Both of these should be settled once the note is published, ie, the proper reference becomes part of specref.

  • I have used the version number 1.1 to differentiate from the IDPF document. One practical reason is that the EPUB-SSV is part of specref referring to the IDPF document and, for historical reason, I do not think we should modify this. Also, we may want to change something on the vocabulary, so it is better to keep this one separate.

The readable version of the new note is here.

Fix #1763


Preview | Diff

@iherman
Copy link
Member Author

iherman commented Oct 12, 2021

@mattgarrish an editorial note: any change on biblo.js triggers a new publishing round on all documents, which is a bit of a drag. The question is: do we really need biblio.js? Afaik, only the Overview document uses extra bibliographic entries for the history part (and some of those may actually be in specref), and otherwise it may be unnecessary. Just to reduce the load...

WDYT?

@mattgarrish
Copy link
Member

The question is: do we really need biblio.js?

It's used by more than the overview. I did a quick test and stripping it from the core spec resulted in 14 broken references. I know the accessibility specs will also break without it, and almost certainly the rs spec if the core breaks.

Maybe we should make per-specification biblio files so we know what's being used where? It would also avoid triggering every spec on a change. It's not like we add to it very often anymore, and additions now would most likely be restricted to one document.

@iherman
Copy link
Member Author

iherman commented Oct 12, 2021

Maybe we should make per-specification biblio files so we know what's being used where? It would also avoid triggering every spec on a change. It's not like we add to it very often anymore, and additions now would most likely be restricted to one document.

I would be happy with that, too.

@iherman
Copy link
Member Author

iherman commented Oct 12, 2021

Actually, in some cases, 1-2 entries would suffice, which does not even warrant a separate file.

I will take a stab at the Overview for a start and see where it goes. I will also remove it right away from this ssv draft.

@iherman
Copy link
Member Author

iherman commented Oct 13, 2021

I have carried over the effects of #1848: no reference to the common biblio file from the ssv note, and picked up the new version of the core/index.html file that relies on a local biblio file.

@iherman
Copy link
Member Author

iherman commented Oct 13, 2021

The readable version of the new note is here.

@mattgarrish
Copy link
Member

The only weird thing is giving it a version number, as it was intended as a living document. That said, I don't think there's any way to go back through all the old iterations, so it's not really a blocker to me.

@dauwhe dauwhe merged commit 7339274 into main Oct 14, 2021
@dauwhe dauwhe deleted the ssv-note branch October 14, 2021 23:18
@iherman
Copy link
Member Author

iherman commented Oct 15, 2021

The issue was discussed in a meeting on 2021-10-14

List of resolutions:

  • Resolution No. 1: Publish the SSV as a working group note, using ECHIDNA, using the short name "epub-ssv"
View the transcript

1. Publication of Structural Semantics Vocabulary as Working Group Note

See github pull request #1847.

See github issue #1763.

Dave Cramer: last week we resolved on separating SSV into a wg note
… we just need a formal resolution to publish it, and to use echidna

Proposed resolution: Publish the SSV as a working group note, using ECHIDNA, using the short name "epub-ssv" (Wendy Reid)

Murata Makoto: the link in Ivan's message doesn't work, so I can't see the note

Dave Cramer: https://github.com/w3c/epub-specs/blob/main/epub33/ssv/index.html

Wendy Reid: See The editor's draft for the note

Dave Cramer: +1

Wendy Reid: +1

Matthew Chan: +1

Matt Garrish: +1

Toshiaki Koike: +1

Masakazu Kitahara: +1

Shinya Takami (高見真也): +1

Murata Makoto: does this document have to do with the IMS Global Consortium? Do they need to see this?

Matt Garrish: no, i think this originally came from DAISY

Murata Makoto: what about the content under sec. 10?

Matt Garrish: this is all stuff that came from us, we don't have dependence on any other party

Resolution #1: Publish the SSV as a working group note, using ECHIDNA, using the short name "epub-ssv"

Dave Cramer:

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Should all Structural Vocabulary Items be normative?
4 participants