See also: IRC log
Finish edits and convert time zones document to HTML
<r12a> http://www.w3.org/International/track/actions/open
Talk with Bert about how to deal with change marks in Ruby spec
Talk with Bert about how to deal with change marks in Ruby spec
Create wiki page with normalization position paper
agenda item for today
Review Contacts API and collect last call comments for the WG. WG members to perform review.
will start this week
everyone: should help koji out
Reply to WOFF indicating our acceptance/non-acceptance of issues per 2011-06-01 telecon
<scribe> done; they are having a telecon concurrently and will discuss last open issue (splitting items into localizable elements)
close ACTION-44
<trackbot> ACTION-44 Reply to WOFF indicating our acceptance/non-acceptance of issues per 2011-06-01 telecon closed
Publish qa-personal-names for wide review
not done; need to respond to Mark's comments
Dump charmod-norm and add disclaimer paragraph, dates, etc. so that we can publish an interim working draft
close ACTION-21
<trackbot> ACTION-21 Review techniques index pages to check that all the current links in the index point to the right place closed
close ACTION-34
<trackbot> ACTION-34 Ask chinese colleagues about character orientation spec closed
chris lilley is likely to contact us to set up a meeting about normalization
<David> http://www.wired.com/gadgetlab/2011/06/microsoft-developers-windows-8/all/1
David: link about Windows8 use of HTML5/JS
- Widgets - HTML5
-Contacts API
<scribe> chair: call to arms on reviewing HTML5
<scribe> Topic : Time Zones document progress
http://www.w3.org/International/docs/timezones/
addison: I think I could nearly almost sorta be done
richard: I have a few comments
<scribe> ACTION: addison: collect any remaining comments and update timezones document for final publication [recorded in http://www.w3.org/2011/06/15-i18n-minutes.html#action01]
<trackbot> Created ACTION-47 - Collect any remaining comments and update timezones document for final publication [on Addison Phillips - due 2011-06-22].
richard: really detailed
(hyper-detailed) and kind of scary
... could use a short article about time zones in HTML5
... "here's how to use the new forms elements"
http://www.w3.org/International/wiki/CharmodNormSummary
http://www.w3.org/TR/charmod-norm/
Specifications MUST require identifiers, namespaces, element names, attribute names, and attribute values to be compared as if they were fully-normalized. Specifications SHOULD NOT require documents to be stored or transcoded to any particular normalization form. However, specifications MAY require specific fields or values within a document to be fully-normalized.
Textual content SHOULD be stored and interchanged in a fully-normalized format, except where it interferes with the author's intentions. give examples
define A "normalization-sensitive operation" is one whose results may differ when normalization is applied to content. define A "normalizing operation" is one whose results are normalization sensitive and which fully-normalizes the text on which it operates.
richard: 3.2.5 defines normalization sensitve operations
A text-processing component MAY perform normalization-sensitive operations without first normalizing or checking for normalization of content. The results of any such operation are dependent upon the code points encoded and visually and semantically identical strings might compare as unequal.
compare -> be treated as
"addison: I like this"
identifiers, namespaces, element names, attribute names, and attribute values
richard: call out authoring tools
and keyboards
... should they provide normalization option or generally
output normalized output??
Authoring tool implementations for a (formal) language that does not mandate full-normalization SHOULD either prevent users from creating content with composing characters at the beginning of constructs that may be significant, such as at the beginning of an entity that will be included, immediately after a construct that causes inclusion or immediately after markup, or SHOULD warn users when they do so.
add a requirement about authoring tools/keyboards/input
<Zakim> fsasaki, you wanted to ask if we should put pointers from each recommendation to specs (as much as there are already) that already do the right thing with regards to normalization
C308 [S] Where operations may produce unnormalized output from normalized text input, specifications of API components (functions/methods) that implement these operations MUST define whether normalization is the responsibility of the caller or the callee. Specifications MAY state that performing normalization is optional for some API components; in this case the default SHOULD be that normalization is performed, and an explicit option SHOULD be used to swit
Specifications of API components (functions/methods) MAY optionally require that normalization is performed for normalization-sensitive operations; the default SHOULD be that normalization is performed, and an explicit option SHOULD be used to switch normalization off.
richard: worried that "full
normalization" creates a lot of complexity
... hard to pin down
... but also created problems such as combining mark inside a
<span> for example
Specifications of text-based languages and protocols SHOULD define precisely the construct boundaries necessary to process the language, protocol, or document format in the absence of normalized textual content. These definitions SHOULD include at least the boundaries between markup and character data as well as entity boundaries (if the language has an include mechanism), SHOULD include any other boundary that may create denormalization when instances of the
addison: deal with combining marks after parsing the document rather than before
Authoring tool implementations for a (formal) language that does not mandate full-normalization SHOULD either prevent users from creating content with composing characters at the beginning of constructs that may be significant, such as at the beginning of an entity that will be included, immediately after a construct that causes inclusion or immediately after markup, or SHOULD warn users when they do so.
addison/richard: not wild about that one
attribute=/foo
where '/' is a combining solidus
\// r12a// this is my comment //
put a couple of spaces on the front
<scribe> ACTION: addison: update charmodsummary and review WG member comments as they come in [recorded in http://www.w3.org/2011/06/15-i18n-minutes.html#action02]
<trackbot> Created ACTION-48 - Update charmodsummary and review WG member comments as they come in [on Addison Phillips - due 2011-06-22].
- should UTF-8 BOM trump document encoding - changes to text/* default character encoding
latter is an internet-draft
addison: add review of tracker issues to agenda for each week going forward
<r12a> http://www.w3.org/International/track/products/6
<r12a> http://www.w3.org/International/track/products/7
<r12a> http://www.w3.org/International/track/issues/24
"do we need complex ruby?"
koji: personally am for complex
ruby
... but some folks don't agree
addison: need to be able to
produce print-grade publications
... can we be forward looking here? or is that too hard?
<r12a> koji: because of form factors, jukugo-ruby is likely to be more important for browsers and mobile devices than for print
<r12a> ... according to discussions in kyoto
<r12a> ... particularly for wrapping text in narrow columns
r12a: need to work out if possible in current html5 ruby model
koji: epub guys interested, but
busy to ship epub3
... will try to get information from epub guys this
week
<scribe> ACTION: koji: contact epub folks and see if jukugo-ruby can be supported with html5 markup or if something else is needed [recorded in http://www.w3.org/2011/06/15-i18n-minutes.html#action03]
<trackbot> Created ACTION-49 - Contact epub folks and see if jukugo-ruby can be supported with html5 markup or if something else is needed [on Koji Ishii - due 2011-06-22].
addison: me too.
<David> bye