[minutes] i18n telecon 2012-03-07

http://www.w3.org/2012/03/07-i18n-minutes.html





Internationalization Core Working Group Teleconference

07 Mar 2012

    [2]Agenda

       [2] 
https://lists.w3.org/Archives/Member/member-i18n-core/2012Mar/0001.html

    See also: [3]IRC log

       [3] http://www.w3.org/2012/03/07-i18n-irc

Attendees

    Present
           Addison, David, Norbert, Richard, Felix, Andrew

    Regrets
           Mati, John

    Chair
           Addison Phillips

    Scribe
           Addison Phillips

Contents

      * [4]Topics
          1. [5]Agenda
          2. [6]Action Items
          3. [7]Info Share
          4. [8]What Time is this Meeting At?
          5. [9]JLReq II publication
          6. [10]Clearing issues in "prep"
          7. [11]AOB?
      * [12]Summary of Action Items
      __________________________________________________________

Agenda

Action Items

    <r12a> [13]http://www.w3.org/International/track/actions/open

      [13] http://www.w3.org/International/track/actions/open

    close ACTION-102

    <trackbot> ACTION-102 Run the time change poll closed

    close ACTION-104

    <trackbot> ACTION-104 Raise IRI product in tracker closed

    richard: raised four new products in tracker
    ... to support the various IRI documents

Info Share

    richard: MLWeb workshop next week
    ... 167 registrations
    ... expect over 100 actual attendees

    norbert: SF Globalization forum (sort of an "IMUG for San
    Francisco"
    ... will post slides of the first talk

    richard: Unicode Tutorial Day at Loc World Paris
    ... in June (like maybe the 4th)

What Time is this Meeting At?

    [14]http://www.doodle.com/45kfma9z32wckkbq

      [14] http://www.doodle.com/45kfma9z32wckkbq

    David: put in your choices... need to make the change quickly

JLReq II publication

    [15]http://www.w3.org/TR/2012/NOTE-jlreq-20120403/

      [15] http://www.w3.org/TR/2012/NOTE-jlreq-20120403/

    richard; Need publication approval for Working Draft

    norbert: some pictures missing
    ... such as 2.23

    <scribe> chair: objections to publishing a WD?

    Norbert: as long as it has pretty pictures

    <r12a> i'm ok to publish

    richard: okay

    addison: okay

    <David> I'd be happy with it as a WD

    norbert: okay

    <fsasaki> fine by me

    Approved for publication as a Working Draft

Clearing issues in "prep"

    [16]http://lists.w3.org/Archives/Public/public-i18n-core/2012Ja
    nMar/0083.html

      [16] 
http://lists.w3.org/Archives/Public/public-i18n-core/2012JanMar/0083.html

    [17]http://www.w3.org/International/track/products/10

      [17] http://www.w3.org/International/track/products/10

    norbert: issue 77, maybe close it?
    ... issue-78, ian didn't understand what we're asking for
    ... I don't either?

    [18]http://www.w3.org/International/track/issues/78

      [18] http://www.w3.org/International/track/issues/78

    richard: this shouldn't be in prep any more
    ... should be able to disable spell check for items that are
    not appropriate

    norbert: html5 spellcheck is about spellchecking in editable
    fields in a user-agent document

    addison: about adding attribute for tools that work on html
    documents
    ... would like to publish the first list without further review
    here; objections?

    ISSUE-105: Compatibility caseless matching

    <trackbot> ISSUE-105 Compatibility caseless matching notes
    added

    [19]http://www.w3.org/International/track/issues/105

      [19] http://www.w3.org/International/track/issues/105

    richard: remove the "either"?
    ... from the recommendation

    They both have a name attribute, their name attributes are not
    empty, and the value of a's name attribute is a compatibility
    caseless match for the value of b's name attribute.

    addison: remove (c) part, remove the "either" from
    recommendation

    I would suggest replacing compatibility caseless matching with
    canonical caseless matching.

    richard: might be two bugs? one for reference and one for
    recommendation

    approved

    ISSUE-106: When the character cannot be encoded into the target
    encoding

    <trackbot> ISSUE-106 When the character cannot be encoded into
    the target encoding notes added

    [20]http://www.w3.org/International/track/issues/106

      [20] http://www.w3.org/International/track/issues/106

    Deals with processing URLs. The steps here result in defining
    the "character encoding" of the URL, which is applies to the
    query portion of the URL. I put character encoding in quotes,
    because what it really is the character encoding of the
    document or script containing the URL as a string. Step 8.2
    contains an implicit encoding conversion (to the document
    character encoding). A health warning should be supplied about
    what to do when the character cannot be e

    scribe: so make explicit the conversion and state that not all
    characters go into all encodings

    approved

    ISSUE-115: Should Document.charset and Document.characterSet be
    harmonized?

    <trackbot> ISSUE-115 Should Document.charset and
    Document.characterSet be harmonized? notes added

    [21]http://www.w3.org/International/track/issues/115

      [21] http://www.w3.org/International/track/issues/115

    Document.charset and Document.characterSet appear to be the
    same thing, although charset has some additional capabilities
    and restrictions. Should these be harmonized? (Is
    'characterSet' new? If so, we'd probably prefer to see
    "encoding" used instead)

    norbert: not in the editor's draft

    addison: still in TR?
    ... "if this makes a return..." ?

    close as obsolete

    ISSUE-116: Setting and getting the direction of the title
    attribute

    <trackbot> ISSUE-116 Setting and getting the direction of the
    title attribute notes added

    [22]http://www.w3.org/International/track/issues/116

      [22] http://www.w3.org/International/track/issues/116

    richard: drop, since handled by bug Aharon raised

    addison: is that 16160?

    richard: yep

    note in issue that covered by that bug and close

    120: Non-ASCII Unicode characters in data-*

    There is a note that reads: -- All attributes on HTML elements
    in HTML documents get ASCII-lowercased automatically, so the
    restriction on ASCII uppercase letters doesn't affect such
    documents. -- Later in the section there are several references
    to ASCII-lowercasing and ASCII-uppercasing operations. There is
    no discussion of how to handle non-ASCII Unicode values (the
    wisdom of any such appearing in this context is, of course,
    open). Default Unicode case f

    A custom data attribute is an attribute in no namespace whose
    name starts with the string "data-", has at least one character
    after the hyphen, is XML-compatible, and contains no characters
    in the range U+0041 to U+005A (LATIN CAPITAL LETTER A to LATIN
    CAPITAL LETTER Z). All attributes on HTML elements in HTML
    documents get ASCII-lowercased automatically, so the
    restriction on ASCII uppercase letters doesn't affect such
    documents.

    clarify that it's ascii-only or clarify what to do with
    non-ASCII since XML-compatible allows....

    approved

    123: Insertion of U+202C

    There is one sentence that reads: -- However, the use of these
    characters is restricted so that any embedding or overrides
    generated by these characters do not start and end with
    different parent elements, and so that all such embeddings and
    overrides are explicitly terminated by a U+202C POP DIRECTIONAL
    FORMATTING character. -- Shouldn't there be an explicit
    statement such as "any end tag for a run of phrasing content
    must be treated as if a U+202C had bee

    Text content in HTML elements with child Text nodes, and text
    in attributes of HTML elements that allow free-form text, may
    contain characters in the range U+202A to U+202E (the
    bidirectional-algorithm formatting characters). However, the
    use of these characters is restricted so that any embedding or
    overrides generated by these characters do not start and end
    with different parent elements, and so that all such embeddings
    and overrides are explicitly termina

    <p> <LTR>This is text<b>and<POP></b> more text.</p>

    <r12a> <p><span>......</span>......</p>

    needs more attention: aharon?

AOB?

    <r12a>
    [23]http://www.w3.org/International/reviews/review-instructions

      [23] http://www.w3.org/International/reviews/review-instructions

    richard: info share: sent a spec by Anne v.K.
    ... specifies encodings that should be supported by browsers
    ... looking for a publication home
    ... add to agenda for two weeks from now

Summary of Action Items

    [End of minutes]


-- 
Richard Ishida
Internationalization Activity Lead
W3C (World Wide Web Consortium)

http://www.w3.org/International/
http://rishida.net/

Received on Monday, 12 March 2012 06:19:32 UTC