RE: InkML review: first draft of comments

Hi Richard,

Many thanks for reply. Only a minor follow up below.

2006-12-20 (水) の 15:31 +0000 に Richard Ishida さんは書きました:
> Hi Felix,
> 
> Thanks for your comments. See below...
> 
> 
> ============
> Richard Ishida
> Internationalization Lead
> W3C (World Wide Web Consortium)
> 
> http://www.w3.org/People/Ishida/
> http://www.w3.org/International/
> http://people.w3.org/rishida/blog/
> http://www.flickr.com/photos/ishida/
>  
> 
> > -----Original Message-----
> > From: Felix Sasaki [mailto:fsasaki@w3.org] 
> > Sent: 20 December 2006 08:40
> > To: Richard Ishida
> > Cc: public-i18n-core@w3.org
> > Subject: Re: InkML review: first draft of comments
> > 
> > Hi Richard,
> > 
> > Here are some comments on your comments:
> > 
> > Comment 3: "We strongly recommend that this be replaced with 
> > references
> > to the IETF's BCP 47, which is the current standard for language
> > values." I would propose to replace "language values" with "language
> > tags". The values are defined - among others - in ISO standards.
> > Also: "If people use ISO639" > "If people use values from ISO639"
> 
> Changed to 
> "<p>The description of the encoding attribute and the example a little further down both refer to ISO 639 as a potential source of codes for language values.</p>
> <p>We strongly recommend that this be replaced with references to the IETF's BCP 47, which is the current standard for language tags, and should be used for such values. If people use ISO639 to derive these tags  they will be severely limiting their ability to express language, and will encounter issues about which of the ISO 639 codes should be used for a given language when multiple codes exist. </p>" 
> 
> 
> > 
> > Comment 4: will you fill this or drop it?
> 
> Oh darn.  We had a problem of the mouse for the home computer driving the cursor on my work computer, and Kenzo slashed my original unsaved copy by playing some computer games.  I missed this in the reconstruction. I can't remember my original text, but have added the following:
> 
> "<p>Note that script information comes for free these days with language tags, if you are using BCP 47. Would this be sufficient for the needs of the user here?</p>
> <p>If BCP47 is not recommended to cater for script information, then you should recommend the use of <a href="http://www.unicode.org/iso15924/iso15924-codes.html">ISO 15924</a> to identify scripts in an interoperable and well-reasoned fashion.</p>"
> 
> 
> > 
> > Comment 5: on "It isn't clear whether the script designation 
> > applies to
> > the markup content or to the traces.
> > Again, this comes for free with BCP 47, which now supports script
> > subtags as part of a language tag (see Language tags in HTML 
> > and XML)."
> > Do you mean "this comes for free with xml:lang"? If not, 
> > better replace
> > "Again, this" with "Script designation".
> 
> Changed to
> "Again, BCP 47-based language tags now support script subtags as part of a language tag (see <a href="http://www.w3.org/International/articles/language-tags/">Language tags in HTML and XML</a>)."
> 
> 
> > 
> > Comment 6: "Please consider allowing for such markup on 
> > natural language
> > text such as found in annotations." Maybe you should make 
> > clear that we
> > don't require that such markup is processed by an InkML implementation
> > itself. It can be processed by an implementation for display,
> > independent of InkML. I'm proposing this to avoid the pushback we got
> > from the PLS 1.0 folks.
> 
> We are asking them to 'consider' this because I'm not 100% sure that annotations are the only place where natural language text appears.

I'm only concerned about potential unclearness in this statement:
> It's not clear to me that such markup would not be processed by an InkML implementation.
I think the question is whether we want to push for an InkML
implementation to *require* such processing. Of course, everybody is
free to do that kind of processing, but I did not see a requirement for
that (i.e. no need for a "an InkML implementation MUST (RFC 2119)
process diretionality markup"). I think people will read InkML documents
(if they read them at all) in XML or text editors, so display is not of
InkML business. To put it differently: I agree with your comment in
mind, I'm just looking for a way to sell it to the people while avoiding
resistance.

> 
> 
> > 
> > Comment 7: I really would like to know more about the InkML use case
> > before we recommend them to always use an time zone offset. 
> > Look at our
> > recommendations at
> > http://www.w3.org/TR/2005/NOTE-timezone-20051013/#d2e382 : There are
> > three different recommendations for field-based time (the 2nd, 3rd and
> > 4th bullet point). I would point them to these bullet points and say
> > s.t. like "there are various use cases for field based time. Which one
> > is yours? You should decide that and accordingly omitt the time zone
> > offset / always supply it  / supply it if and only if the 
> > time value is
> > really fixed".
> 
> Actually take a look at the recommendations we made in that document for Xquery/XSLT in section 1.5: http://www.w3.org/TR/2005/NOTE-timezone-20051013/#d2e464

I'd say these don't apply necessarily, but rather the general ones which
I pointed to above, see
http://www.w3.org/TR/2005/NOTE-timezone-20051013/#d2e382

> 
> The first of those recommendations basically makes the same point as we are making for InkML review,


We have to be careful not to contradict ourselves. Look at the second
bullet point at
http://www.w3.org/TR/2005/NOTE-timezone-20051013/#d2e382 : "If all of
the data values are used to represent time zone independent values (such
as a list of employee's birth dates), then the zone offset should always
be omitted. ..." So if InkML falls under this category, the
recommendation would be not to have time zone information at all.

As a compromise, how about the following :
"We believe that you should require that all timeString values contain
time zone offsets as defined and explained in "Working with Time Zones"
and adding "If time zone offsets are not important for your usage
scenario of timeString, you might use UTC 'Z' to easy implementation".

>  and the others are there for the situation where that cannot be enforced.  I think that in the inkML scenario we have intercepted the spec early enough that such things can be enforced, and if I correctly understand what I read, that would be an appropriate course given the way that time stamps are used in InkML.  I therefore think that it is clearer for them to simply recommend what we feel would be the best solution - and I'm even starting to think that we should make our proposal clearer by saying 'It is very difficult to compare timestamps with and without time zone offset information. We believe that you should require that all timeString values contain time zone offsets as defined and explained in "Working with Time Zones".'  It is their job to decide whether or not that is appropriate, and to come back to us if it is not, but at least we have started with clear advice to them.


> 
> {Off topic: I have read the Working with Timezones Note a few times now, and each time found it rather frustrating. Much of the information is excellent, but I struggled with the overall organization, and, in particular, had to work at extracting a set of simple guidelines. It is written mostly like an essay rather than a set of best practise recommendations, which I think is a shame.  In particular, the advice at the very end provides the clearest set of recommendations, but they aren't really tied in to the rest of the text.  If ever we get round to updating the Note, perhaps we could bear that in mind. }
> 

Agree. The document was written with the "Best practices" statements
being created at the end. A rewrite could start from "BP" statements and
when explain why.

Felix

> 
> > 
> > Felix
> > 
> > 
> > 2006-12-18 (月) の 20:31 +0000 に Richard Ishida さんは書きました:
> > > At http://www.w3.org/International/reviews/0612-inkML/
> > > 
> > > Let's discuss during the telecon, if possible.
> > > 
> > > RI
> > > 
> > > 
> > > ============
> > > Richard Ishida
> > > Internationalization Lead
> > > W3C (World Wide Web Consortium)
> > > 
> > > http://www.w3.org/People/Ishida/
> > > http://www.w3.org/International/
> > > http://people.w3.org/rishida/blog/
> > > http://www.flickr.com/photos/ishida/
> > > 
> > > 
> > 
>

Received on Wednesday, 20 December 2006 16:15:13 UTC