Internationalization Core Working Group Teleconference

Agenda

Action Items

<r12a> 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?

http://www.doodle.com/45kfma9z32wckkbq

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

JLReq II publication

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"

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

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?

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

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

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

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

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> 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