Meeting minutes
Agenda Review
Normativity of i18n-glossary
<addison> The i18n-glossary is a NOTE. This causes problems when referencing it in normative specs. We suggested making this okay, but there has been push back. Inviting PLH to attend to discuss.
addison: invited PLH, on status of i18n glossary
<plh> GitHub: w3c/
<gb> Issue 269 Make I18N Glossary definitions okay in normative blocks (by aphillips)
addison: we have suggestion on references in normative section, etc.
plh: complementaly to INFRA spec
addison: INFRA is normative one, which others are referencing
… our glossary keep overlap with them
PLH: we could use/rely on INFRA, but for glossay to use we need to bring thing into rec-track
r12a: all of our stuff are educational one, instead of definitions
… for rec-track, we have definitions which INFRA already has
… we explain things in more educational purpose
plh: duplication is not issue, we have already some. concern on not at rec-track
r12a: INFRA is mainly focusing on HTML, our glossary is more wider view
… could conflict in that way
… when we change our glossary definition, which happens many times, specs picking terminology form them could affect
… some spec copies text from our glossary
plh: proposal to link to glossary from specs
addison: formal definition could be linked from rec-track, to provide definition, and our glossay can add some related terminology/definitions
plh: could be referred from normative section, also you can attach informative part as note to term definition
… adding note to let people know about difference, like code points example
… going to normative is not so heavy, we could stick at CR without going to REC
… could have little bit flexibility on handling
plh: for implementation, we could do some, and there are real example in long past
addison: we may need to rechater to include
plh: let me check, but charter might have some text for rec-track document in scope?
plh: scope explicitly exclude rec-track document, for now
… I think right thing to add as rec-track, stability as well
[discussion on tooling for current handling]
<addison> https://
addison: we would need to refactor glossaly into normative and note
r12a: we may have both even for term
plh: agree, before we do rechartering we need to dig into these filtering on terminology and definitions
<xfq> w3c/
<gb> Issue 904 Glossaries: a different pattern needed? (by cwilso)
xfq: there are already related discussion in process issue
<xfq> w3c/
<gb> CLOSED Issue 270 Normative reference to informative definition (by ProgramMax) [i18n-tracker] [blocking-3rd-edition-cr]
xfq: specific spec issue is in png spec
plh: thank you for pointing this issue xfq, and bring into process CG in two weeks
addison: we need to install regulatory to align with Process, informative and normative candidates
… careful look into informative ones, turing into normative description
plh: might not into rec-track, but potential to registry
<plh> A registry report or registry section is purely documentational, is not subject to the W3C Patent Policy, and must not contain any requirements on implementations. For the purposes of the Patent Policy [PATENT-POLICY], any registry section in a Recommendation track document is not a normative portion of that specification.
plh: to reference registry in normative rec-trac spec, example in png spec.
… can use registry for these case, should be questioned
… more requirement on registry than group note
plh: want to inject some more questions
<plh> https://
plh: added panel to horizontal board as above
… looking into agenda+ label
<addison> (I have more kinds of Agenda+ labels too)
<plh> https://
plh: is there need from i18n to add section markers? (see email in horizontal review request mail list
<xfq> w3c/
<gb> Issue 162 standard way to mark fingerprinting surface vectors (by marcoscaceres)
addison: amazing tool to have, since we are putting items into note
… so let us think about
<addison> https://
plh: if you want, please join process CG call, in any case, I will report back
Info Share
r12a: safari released, and supports ruby position in charactor
… bopomofo lines in one line, not separating tone marks...
<addison> w3c/
<gb> Pull Request 149 Address differences between DESIGN-PRINCIPLES and SPECDEV (by aphillips) [Agenda+] [Best Practice] [normative]
addison: welcome comments on above PR