See also: IRC log
approved
<scribe> ACTION: all to give feedback on LTLI update (PENDING) [recorded in http://www.w3.org/2006/12/19-i18ncore-minutes.html#action01]
<scribe> ACTION: Felix to go back to schema people with our test ideas for XML Schema (DONE) [recorded in http://www.w3.org/2006/12/19-i18ncore-minutes.html#action02]
<scribe> ACTION: Felix to see what has to be updated on tutorial material for IDNA issues (DONE) [recorded in http://www.w3.org/2006/12/19-i18ncore-minutes.html#action03]
http://lists.w3.org/Archives/Public/public-i18n-core/2006OctDec/0045.html
Felix: should we bring that to GEO?
Richard: might be good to include
the GEO folks in a separate mail
... on the proposal in general: what makes certain things
invalid?
<r12a> http://www.ietf.org/internet-drafts/draft-alvestrand-idna-bidi-00.txt
francois: the RFC says that it
must end with a strong RTL or LTR character
... a combining character is not possible, that is the
issue
richard: what about control characters?
francois: don't found the word joiner in the draft
richard: the article tries to be
very high level
... linking to an RFC is s.t. we would try to avoid
francois: here it is even no RFC, but a draft which will expire
(discussion on how to bring the information of the internet draft into i18n activity material)
richard: have a short note in the article about "combining characters should not be at the end of a label" would to it, right?
felix: yes
richard: how about a blog entry about the detail? This is better than an article, since the issue is of temporal interest
felix: fine with me
francois: the IRI / IDN article
needs to mention the issue
... also the pages on browsers
richard: these pages have a
section saying "does it work today?"
... these need an update
francois: current status is: they
have reanabled them and they have a white list
... so does it work? yes, but: there are restrictions (TLDs,
RTL scripts)
richard: yes, we could add s.t.
in the article as well
... Michael, would you like to do s.t. like that?
Michael: sure
<r12a> http://www.w3.org/International/articles/idn-and-iri/#work
<scribe> ACTION: Michael to propose an update to the section in the IRI - IDN draft "does it work?" about domain names, see what needs to be sad these days [recorded in http://www.w3.org/2006/12/19-i18ncore-minutes.html#action04]
<scribe> ACTION: Richard to add the alverstrand draft to the IRI / IDN article [recorded in http://www.w3.org/2006/12/19-i18ncore-minutes.html#action05]
<scribe> ACTION: Felix to prepare a text of a blog entry about the IRI / IDN issue in the alverstrand draft and send it Richard [recorded in http://www.w3.org/2006/12/19-i18ncore-minutes.html#action06]
Richard: write it an news paper style, to help people
<scribe> ACTION: Felix to update LTLI with "or its successor " statements (DONE) [recorded in http://www.w3.org/2006/12/19-i18ncore-minutes.html#action07]
<scribe> ACTION: Francois to look after ISO locale related spec (DONE) [recorded in http://www.w3.org/2006/12/19-i18ncore-minutes.html#action08]
<fyergeau> ISO TR 14652
francois: was later replaced (not
officially, but effectively) by the Unicode CLDR
... it had many problems. But some linux systems made use of
that data
... may be worth mentioning in LTLI, just for
completness
<scribe> ACTION: Felix to write a mail about possibility for SVG tiny specific IRI tests to martin and the i18n core list (PENDING) [recorded in http://www.w3.org/2006/12/19-i18ncore-minutes.html#action09]
felix: might phone chris and ask him
francois: yes
<scribe> ACTION: Francois to build a current issues list on charmod norm (PENDING) [recorded in http://www.w3.org/2006/12/19-i18ncore-minutes.html#action10]
<scribe> ACTION: Francois to have a look at issue 3698 and gather information on options for diacrictics in collations (PENDING) [recorded in http://www.w3.org/2006/12/19-i18ncore-minutes.html#action11]
<scribe> ACTION: Francois to review InkML LC draft (DROPPED) [recorded in http://www.w3.org/2006/12/19-i18ncore-minutes.html#action12]
richard: I reviewed InkML, we can discuss it today if possible
<scribe> ACTION: Richard to find out what is the canonical URI for BCP47 (ONGOING) [recorded in http://www.w3.org/2006/12/19-i18ncore-minutes.html#action13]
Francois: the IETF points to the RFC-Editor officially , so I'm not convinced by Martin's arguments
(Felix summarizes the discussion)
Francois: we had sad that a test
for an attribute typed as anyURI would be valuable
... we should go back to them and insist
felix: agree
francois: one IRI in the test suite to verify anyURI would be good
<scribe> ACTION: Felix to go back to XML Schema people with WG reply on IRI tests [recorded in http://www.w3.org/2006/12/19-i18ncore-minutes.html#action14]
(Felix gives a summary of last week's discussion)
Francois: the TAG document uses
"best practices" as "normative statements"
... they just go on and say "this is a good practice"
... we could do the same thing by removing section 6
... at
http://www.w3.org/International/core/langtags/#sec-locale-vs-language
... we could remove that section and maybe also sec. 5, or
rewrite it
Mark: what in sec. 6 should not be normative?
Francois: statement 1 "Specifications that make use of language tags or locale values MUST meet the conformance criteria defined for "well-formed" processors, as defined in sec. 2.2.9 of [RFC 4646]."
Mark: well-formed is just the syntax
Francois: we want to say "refer to BCP 47"
Mark: there is a value in
statement no. 2
... there are circumstances where you don't want to validate
values
... if s..t comes from a trusted source
... it is unlikely, but it could happen
francois: RFC 4646 and 4647: don't these documents discuss such things?
Mark: these docments describe
what it means to be valid / well-formed
... the wording in sec. 6 of LTLI is nice; RFC 4646 it does not
say you have to validate
... the statements 1 and 2 are useful
... no 1 in particular is very useful
... esp. for other w3c specs
... no. 2 is slightly less valuable, because it is like saying
"I conform to RFC 4646"
Francois: we want to tell spec
writers that they have to use whose definitions from RFC
4646
... were are going for validity, Mark?
Mark: for validity, you check the
registry
... you make a copy of the registry
... checking against a list of subtags
Francois: were do you want to
place the obligation to check validity or
well-formedness?
... take e.g. xml:lang? XML Core WG discussed what validation
should be done for xml:lang
... the parser does not do anything to language tags except
passing it to the application
Mark: there is a backwards
compatibility issue here
... the new syntax in RFC 4646 is narrower than RFC 3066
Francois: even the narrow syntax
of RFC 3066 was removed from the xml spec
... in the HTTP protocol: should an HTTP receiver check the
well-formedness of tag?
Mark: there is a lot of crap in
these area, we did a lot of tests
... e.g. accept-lang can contain a word like "spanish" or
complete rubbish
... you could say "XML parser MUST validate"
... another possibility to say "it could only be interpreted if
valid"
Francois: that sounds better. You
cannot write any type of spec with a MUST to check
well-formedness
... the XML spec does not satisfy no. 1, and there is no need
to do that
Mark: the weakest thing we should
say: if you interpret the language tag, interpret it as RFC
4646
... actually BCP 47
RESOLUTION: agreement to have a statement like "if you interpret the language tag, interpret it as RFC 4646" in LTLI
Francois: if you have a
specification which includes language tagging
... you MUST say "this must be according to BCP 47"
... we should say: Specifications that specify language tagging
of any short should say that the semantics and syntax or that
should folow BCP 47
... without forcing implementations of the spec to do so
RESOLUTION: Have a statement like "Specifications that specify language tagging of any short should say that the semantics and syntax or that should follow BCP 47 without forcing implementations of the spec to verify wellformedness or validity" in LTLI
Mark: we could have one further
statement like
... if I "hit" a language tag that is not well-formed or
invalid, I should not interpret it as a language tag
... example: xml:lang says "English". That is an invalid tag. I
should not interpret it
... this is saying "this is what you have to do if you get an
invalid tag?"
... if I process UTF-8 and get e.g. C080
francois: it is like the xml spec which says "if you are not well-formed, you should stop processing"
mark: we don't need to stop, you
could e.g. transform the invalid value into s.t. valid
... but what you should not do is interpret it into s.t. that
propagates the error
mark: there is a dicussion on
IDNs ongoing
... it would be good to join
Francois: it is an IETF list?
Mark: I send the information to the core list.
<r12a> http://www.w3.org/International/reviews/0612-inkML/
<r12a> http://www.w3.org/TR/2006/WD-InkML-20061023/
richard: they don't use xml:lang
anywhere
... I'm saying "why?"
... I'm also saying "xml:lang should be used for indicating the
language of the document"
... I want to confirm with you that xml:lang is not appropriate
for following the traces
Francois: I disagree
... if the document has traces, xml:lang can apply to the
traces
richard: an element like
<annotation
type="contentCategory">Text/en</annotation> can be
used to say what language the traces should be
... I'm happy with them not using xml:lang here
Francois: xml:lang has strict scoping rules, which don't apply for <annotation type="contentCategory">Text/en</annotation>, so it's good not to use xml:lang here
Richard: the same in SSML
... now on comment 11: about time string
... they create a time stamp
(people will look at the comments today or tomorrow, Richard will send them out tomorrow)
next weeks meeting cancelled, good holiday for everybody