W3C home > Mailing lists > Public > public-i18n-core@w3.org > January to March 2005

RE: Internationalization Core comments on XHTML2 (PR#7677)

From: Richard Ishida <ishida@w3.org>
Date: Tue, 22 Mar 2005 17:56:43 -0000
To: "'Richard Ishida'" <ishida@w3.org>, <public-i18n-core@w3.org>
Message-Id: <20050322175643.81CB64F093@homer.w3.org>

Points we may want to discuss wrt the XHTML2 response to our comments.

Original comments at:
http://www.w3.org/International/2004/10/xhtml2-i18n-review.html


RI


> From: public-i18n-core-request@w3.org 
> [mailto:public-i18n-core-request@w3.org] On Behalf Of Richard Ishida
> Sent: 16 March 2005 12:44

> Many thanks for your comments, which we discussed at the 
> just-finished face-to-face. You can find the discussions at:
> 
> http://www.w3.org/2005/03/03-html-minutes.html
> http://www.w3.org/2005/03/04-html-minutes.html
> 
> However, here is a summary.
> 
> 5: Accept. This will cause the value of the encoding 
> attribute to be used in the accept-charset field of the HTTP 
> headers, in order to give priority to that encoding when 
> requesting the document.

We should ask for clarification about whether changes will be made to XHTML
Modularization spec.

> 
> 7: Accept. Furthermore, we do already point to the XML spec 
> as the normative definition.

Ditto

> 
> 7a: We believe that section 14.1 is the correct section.

Section 14.1 is 'Accept'.
Section 14.4 is 'Accept-Language'

> 
> 8: It means decimal digits [0-9]. We will correct. Thanks. We 
> are describing lexical structure, so we believe that the 
> current definition is correct otherwise.

Are we happy with just [0-9]?
Push back on use of integer?  Can they be signed, eg. negative?

> 
> 8a. We intend to point to a new version of Modularization. 
> The current version has modules and datatypes we no longer 
> wish to use, so we will not be referencing it.

This bears further investigation as things develop...

> 
> 9. URI is the name of the datatype. Its definition is an IRI. 
> We shall point to the newest IRI spec.
> 
> 10. The attribute set you should be looking at is the one 
> called Common.  
> That is the one that is on all XHTML elements, not Core. Core 
> are just the attributes that don't belong anywhere else.

This section is not very clear.  I don't see anything that says that the
Common set of attributes will be available on any element.


> 
> 14. Accept. We will require xml:lang on the html element.
> 
> 14a. Therefore, accept.
> 
> 21. We propose the following solution. Retain the 'title' 
> attribute for historical and mindshare reasons, but encourage 
> the use of metadata of the following form for cases where 
> markup is needed of the content:
> 
> 	<p id="expl">
> 		<meta about"#expl" property="title">Marked up 
> text here</meta>
> 		.....
> 	</p>
> The title attribute ten just becomes a shorthand.
> The meta element is not required to be a child of the <p>; it 
> may be anywhere in the document.

Looks interesting as a general solution for title. 

Still not happy with using title for expansion, since it doesn't convey the
true semantics about what this string is.

How will applications know that in this case it means 'full-form' as
oppposed to 'do what you normally do with titles here'??

Where is the standard list of properties found?

> 
> 22. We have deleted the sentence in question.

We still don't have a general solution to the pronunciation problem,
however.

> 
> 24. Reject*
> 
> 25. Martin Duerst was present for this discussion, and we 
> agreed that the default would not be to use stylesheets, but 
> to normally require the quotes in the text, but that the 
> author could use stylesheets for those cases where it is 
> better for the quotes not to be in the document.

We should ask that some text be included in the spec to point out the
potential value of such an approach.

We should check that the example is changed to put the quotes outside the
markup.

> 
> We will improve the example.
> 
> 27: Accept.
> 
> 33: Accept.
> 
> 34: duplicate of 21
> 
> 35: We will check the text for ambiguitites.
> 
> 35a: Accept.
> 
> 35b: This should go in a user's guide (which we anticipate producing).
> 
> 35c: Since the behaviour in *correct* situations (i.e. when 
> the document really is in that language) will be identical, 
> and only in error situations will be different (and in XHTML2 
> clearer than in XHTML1), we believe that retaining the name 
> is acceptable.

We need to make sure we understand this and agree.

> 
> 37: Accept.
> 
> 38: Part 1. If this is necessary for XHTML, then it is 
> necessary for all XML-based languages. We would then prefer 
> to see an XML-wide solution, and not an XHTML-specific one. 
> We will consider possible solutions, but would be grateful to 
> see a firmer proposal from you.

We need to consider a firmer proposal.  Could be a job for ITS.


> 
> Part 2. If you need to do this, then please use the <meta> 
> version above.
> 
> 38a. Accept. We will tweak.
> 
> 39. Accept.
> 
> 39a. Accept.
> 
> 40. Accept.
> 
> 41. Accept.
> 
> 42. Accept.
> 
> 42a. You can use <meta about="#yourelement" 
> property="dc:creator">Your Name</meta>

This seems to necessitate ids on many elements.  Is it possible to say <meta
about="_this" ...>Your Name</meta> if the meta element is inside the element
referred to? 

(One could also think about using xpath pointers, eg. <meta
about="//p[xml:lang = 'ar']" ...> )

> 
> 42b. We will attempt to define a datatype that requires the timezone.
> 
> 42c. No. Please see 8a above.
> 
> 43: Accept.
> 
> 44. See 21 above.
> 
> 45. Accept.
> 
> 46. Accept. The HTTP protocol solves the problem you refer to.
> 
> 47. Sentence removed.
> 
> 48. Accept.
> 
> 49. Fixed.
> 
> 50. Accept.
> 
> 51. Thanks for your input.
> 
> Please let us know if any of these responses are unacceptable.
> 
> Many thanks,
> 
> Steven Pemberton
> For the HTML WG
> 
> *Just kidding.
> 
> 
> 
Received on Tuesday, 22 March 2005 17:59:10 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Wednesday, 1 October 2008 10:18:49 GMT