Meeting minutes
Review remaining Actions, https://github.com/w3c/personalization-semantics/wiki/actions
<Lionel> Agenda: Patents
Lisa: Patents going well.
… Bliss has ok'd the W3C copyright. Is this wording sufficient?
Roy: Looks OK, we can go forward. Close this action.
<LisaSeemanKest> https://
Lisa: Agenda, Internationalization (144, 145)
<LisaSeemanKest> I was actioned with reopening this issue by I18N WG. We remain concerned that there are duplicate lists and that, by forking from HTML, you are importing a myriad of internationalization woes from that spec. For example, there are several date and time related fields, but no mention of different non-Gregorian calendar systems. There is a country code type but not a reference to country/region code standards such as IS[CUT]
<LisaSeemanKest> Is it possible to separate this material and use it by reference? Or should we comment in detail on these keywords because you intend them to be distinct from HTML?
John: Likely referring the data purpose attribute
… we lifted that almost wholesale from auto-complete
Charles: Let's add a reference to auto-complete
Lisa: That's what they are asking for.
John: Country code ISO-3166 (is this the same as Lang?)
Lisa: We can say-- the auto-complete standards are included, e.g., ....
John: What duplicate list exactly is he referring to?
John: On WCAG 2.1. Right now autocomplete of HTML 5 has some attributes without browser support
… there was a concern in the WG if we just point to the values of auto-complete
… (keep in mind that WG controls HTML now, not W3C)
… (while WG is evergreen -- not snapshot -- they are aiming to reduce the number of attribute values, partially due to the lack of support by browsers)
… So if we are going to point to a list, I suggest pointing to WCAG section 7 rather than auto-complete
John: did we add any new values?
Charles: Yes
Lisa: date end, date start
Sharon: Sortable (at the end of table)?
Lisa: This is a substantive change. Does it require a CR? Or is it the same content, just from another place?
<LisaSeemanKest> https://
<CharlesL> These are the non auto-complete for data-purpose
<CharlesL> additional-name-initial
<CharlesL> Additional or middle name initial.
<CharlesL> No
<CharlesL> purpose
<CharlesL> answer
<CharlesL> Answer to a section question.
<CharlesL> No
<CharlesL> purpose
<CharlesL> area
<CharlesL> Administrative area, state, province, or region.
<CharlesL> No
John: I see two concerns (1) date and time with no mention on non-Gregorian
… (2) country code type without a country code standard
Janina: What are doing that is unique with date/time? Aren't those handled by the OS?
Lisa: We allow it in different scenarios, to be represented as an icon
… I suggest we agree on how to respond.
… They want us to reference a source
… But they may not have pointed out every issue with a18n
… they mention referencing HTML 5 but we could reference WCAG
… we can go through all individual changes, wherever an a18n issue appears edit that text
… or: take out things that re-occur in WCAG and just reference
… or add an instruction / editor's note reading: many of these also appear in WCAG, where there is duplication or a difference in definition, please use the WCAG definition
… this will allow simpler harmonization
… keep in mind: they may not have mentioned every single issue, as they ask us, "Is it possible to separate this material and use it by reference? Or should we comment in detail on these keywords because you intend them to be distinct from HTML?"
John: Time end, time start, and others like this... we need to harmonize with other standards
… and language.
… maybe perhaps addressing as well, we have address but there may be other levels
… birthday- this implies a time/date component
<LisaSeemanKest> We remain concerned that there are duplicate lists and that, by forking from HTML, you are importing a myriad of internationalization woes from that spec.
<CharlesL> fax-country-code as well
Lisa: Thinking about calendars: we know about this variation, people who use the Israel and Chinese calendars are represented on this call
… it seems they want us to reference autocomplete of HTML 5.
… to reference WCAG could be harder
Janina: We need to pay attention, they are pointing out that these issues may be outside our scope
… I suggest we reach out and say, we agree, what would you propse for us to reference
… keep in mind whoever is implementing the standard needs to know what exactly to implement
John: We tried to deal with this problem in WCAG 2.1.
… What we lack and need is a repository (kind of like TR) for references like this
… this is a big ask, would require an architectural change inside the W3C
… we have a normative reference to the values (via autocomplete) but we do not have a master list
… WCAG list is incomplete. HTML5 is incomplete and might also be modified, as attribute values that we reference might be eliminated
<CharlesL> +1 to invite them
John: as we (and they) do not want us to fork, we need a solution
… let's invite them to a discussion
… this is an issue that we have known about for some time, and now it's time to action it
Lisa: Look at how HTML is doing it in the WG
… Personalization use cases are very experimental.
… answers can depend on context. With birthdays, for example, we select which calendar to go by, based on who is asking and in what context
… we are trying to automate the process of giving instructions, where this kind of automatization can be very important
… and autocomplete may not be providing enough to fulfill these requirements
<JF> https://
Janina: The word 'experimental' is a key word, keep in mind PR and TR are not meant for experimentation
… as to process: seems we are agreeing, let's meet with them.
… we can set guidelines, set the direction we want to go in
<JF> https://
Janina: "there are some issues here, which way did you want us to reference them in?" and we can provide 2 or 3options
… explain the problem we may have
… ask them if they'd like to join
… Volunteer to draft this (action item)? Or should we draft it together?
John: Put two links above, W3C and iso-8601
… we can reference the standards for format value
<JF> https://
John: for date start & date end we could also reference the 'microformats' link above (but it being a wiki is problematic)
Lisa: Let's look more closely. A field accepts a birthday
… we do not have a tag to support entering one's non-gregorian birthday (e.g., Hebrew) in this field
… so a reference does not necessarily help us to conform
John: The W3C date/time link is from 1997
Lisa: I looked at it.
Lisa: When speaking with i18n we will share the challenges we face, kind of like what we went through with WCAG
… regarding date/time format, this might be a red herring. What is the actual problem here? We do not specify the data format here!
… we are not specifying the date/time format here. we are specifying its role
John: Disagree.
… Calendars must share a reference (they share a reference to Western time AFAIK)
Janina: emacs specifies alternate calendars
Lisa: data-purpose has a value that is set, 'birthday'
… this doesn't even have to be a field
… we just say what it is so we can support adding personalization (symbols, instructions as to what it means).
… did we write anywhere that the 'birthday' needs a format in this field?
John: currently. we have bday, bday-month, bday-year. do all calendars share these concepts of day, month, year?
Lisa: Yes
John: propose adding a value, calendar-type
<JF> https://
John: the link above references 12 different calendars
… Gregorian, Julian, Hindu, Buddhist, Islamic, Jewish, Persian, Chinese, Coptic, Ethiopian, Revised Julian, Mayan,
Charles: We could put a form field, but there must be an already agreed-upon method to specify these values
… we dont care what calendar, we are saying that the PURPOSE is for a birthday
… our specification does not say that birthdays are only Western
Lisa: So you propose: we are not stating the format, we are only stating the purpose
… for calendar, there are attributes for that and we recommend you use those attributes
Janina: we may need to specify what kind of calendar it is, e.g., birthday, time/date you are showing up at a hotel
<JF> Normative reference (WHAT WG): https://
Lisa: We propose that we specify we do not imply format. We recommend that you do provide format and reference specifications that you might use
<LisaSeemanKest> this does not suppy format and we recomend that you do by refrencing ....
John: This is a problem that is bigger than us
John: This problem manifests in other places. The language of HTML is english-based, and the computer representation of date/time is Western
… this ctee cannot solve this
… revealing the format of the date is correct
… ISO goes year, month, day, hour, second, ms
… that is a reliable international standard
… and this is not our business
Lisa: So: we should clarify, if you say this is a birthday field, this is a day/time format implied
… but we are not saying that
… we say, if this is a date./time field, we recommend this format
<JF> "The format SHOULD use the ISO 8601 format"
Lisa: BTW, I disagree that the language of the web is English. It is experienced by people each in their own local language. E.g., Chinese speakers only experience the web in Chinese
Lisa: Proposing.
<LisaSeemanKest> note this does not suppy format and we recomend that you do by refrencing ....
<JF> the language of the web is localized. The language of the HTML code is western/english
Lisa: #1: Write a note under purpose. The note states, 'this does not supply the format. for format we recommend that you reference another specification... ' and we provide pointers
… or do we imply a format?
Lisa: Straw Poll. [defines the poll]
John: Country code? ISO spec. Time stamp formats? ISO spec.
… Language of the web is localized, but the code itself is derived from english (e.g., <body>)
… RFC 2119 SHOULD use the timestamp format in 8601 and country code in ____
Lisa: But this is the disagreement.
… Differentiate more clearly between PURPOSE and FORMAT
… we do not specify format
Lisa: Straw Polll proposed...
objections. straw poll, not yet
Janina: We can have a default, a presumption. The presumed format is e.g., Gregorian, if you want Hebrew then you have to specify
Lisa: If you have lang=Hebrew or lang=Chinese, would you assume Gregorian?
… it depends highly on the site
Janina: Can we discover what is the common practice? What are the dates in Baidu?
Roy: The Chinese date is shown.
<Roy> 2021年1月25日
John: That is a Western date.
Roy: Correction. China uses a Western calendar in general, and only use the traditional calendar when involved in a festival or traditional rite
John: This is ISO! Year, Month, Day
Lisa: We cannot really speak for every culture.
Janina: That's why we need to use the existing standards
Lisa: So we say, we do not say what format.
John: Canada and USA cannot even agree on date format (m/d/y vs d/m/y)
… but the three concepts endure. year, month, day (date)
Janina: The programmatic determination is that there are defaults
… we see that even China is conforming
… what is specified meets a certain spec
… let's pt a default. if you are going to specify in a different naming convention, then state it
Lisa: proposing poll again.
Janina: a bit too hard
To be continued!
<JF> I'm with Charles - I like to consult i18n WG
John: I'm saying, we need more info. We accept your feedback as valid, please tell us how to go about it
Lisa: I will write this up
<LisaSeemanKest> https://
'--- trackbot, end meeting