On Friday, May 14, 2004 10:22 PM, Peter Constable wrote: > It is simply inadequate analysis of usage scenarios to say "an > order form contains formatted dates / numbers / currency that need to > be interpreted, therefore this document has a locale".
Sorry, you lost me. I do not know what "usage scenario" are. But if "usage scenario" describes a workflow, if the workflow involve orders, and if the amounts can be written in ambiguous form, I would have thought that, _at some level of the modelisation_, some notion of locale might be present; and then that a realisation (I hope you get my vocabulary of specification right) might have an property "locale id" attached to the "order form" document. This was the scheme I had in hand. Of course, it results that "this document has a locale" is a shorthand. Nevertheless, I did not deny your analysis. Rather, I pointed that I my view, it would be wrong to think that "no document has a locale," which is a quite different thing. In the case it was not clear before, I agree that in most cases, they do not. > But if the <amt> record is *not* in a > neutral representation, then there are several other questions that > need to be considered regarding how the string was generated, and how > the receiver knows what was assumed by the authoring process. Regarding you example: I do envision very well an application that will tag the <amt>, and also the XML document, with some externally defined locale id (and I do not mean language here). And I also have already seen a pair of application doing similar things... Whether this is sensible or not is another debate entirelly: I just point out it could be done. >> And these files do >> include or refer locale ids and language ids, sometimes named one >> for the other BTW. > > Just because someone called the two the same doesn't mean that the > notions are not distinct, and that it wouldn't be helpful for us to > understand that distinction. Again, I am lost: I did not say they are merged, just that some use the name of the former to design the latter. Now, I can accept they may be in fact the same thing, since I am not an expert of this field: just that for me, they appear as different for the moment (and the more I read in this thread, the more I stay on my initial idea that they are different.) >> And what you see as "internal to >> your process" is, to me, actually an usable, external, data. > > If you consider it external, then it is because you expect others to > use what you put there, or you are using what others put there -- and > so it is indeed external. Yes, exactly. >> See my example, >> imagining it is a text processing file: deeply inside, I have found >> the locale id of the sender. Which was an hint, not the real data I >> would have liked. > > If the document includes an ID that indicates the locale mode that was > set in the author's software when the author created that file, and > you wish to use that as a hint to set a processing mode on your end, > I have no problem with that; I have never said anything against that. This is what I missed. I claimed, this ID was considered (by me) as a locale tagging of the document (see above my full reasonment). I never claimed it was intended that way at the beginning, or in other processes, including the ones that will follow the one of recognition of the intended meaning. But in that particular process, it looked very much like a locale id tagging a document to me. > Rather, I'm saying that the conceptual model we have inherited from > the past is inadequate, and that we need to adopt a more > carefully-conceived model around which to design i18n platforms for > the future. This is starting to be interesting: we obviously will have quite of bit of "backward compatibility" (in the minds of the people) to deal with, won't we? > And it starts by understanding that while they may be > related, "locale" and "language" are conceptually two different > things. I never thought such a thing, did I? OTOH, I acknowledged your terse description of the question as being a very good thing (« ce qui se conçoit bien s'énonce clairement, et les mots pour le dire viennent aisément » --the well understood would be explained clearly, and the words to say it will flow easily-- sorry M. de Boileau for the bad English translation) Antoine
