[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [EXT] RE: [cti] Changes to Language Content
|
Hi, Bret, > I am wondering then, who requested that property? I thought it was Fujitsu.
> If no one has requested it, and it was added because we thought it might be needed, then we might want to drop it for now.
> We can always add it later if people actually need it.
I am not sure when/how it made its way into language-content.
Maybe it happened when versioning was hotly debated and
object_modified was added to it for the sake of consistency.
Anyway, I see some rationale behind it (when the text description can be significantly
updated when the original translation is meaningless for the updated object). However, object_modified is not exactly a good indicator for a particular property for its changes as object_modified is for an object, not for an individual property like name and description. We need a better mechanism to deal with it. (I still believe that translation should be text-based, not object-based and that it would make things much simpler/easier, but the idea did not sell very well here.) As such, I am okay with making it "optional" or dropping it totally. Regards, Ryu From: Bret Jordan [mailto:Bret_Jordan@symantec.com]
Ryu, et al., Thanks for that. I am wondering then, who requested that property? I thought it was Fujitsu. If no one has requested it, and it was added because we thought it might be needed, then
we might want to drop it for now. We can always add it later if people actually need it. My personal opinion is we should not add things that people are not going to use or do not have a need for. Bret From:
masuoka.ryusuke@fujitsu.com <masuoka.ryusuke@fujitsu.com> Hi, Allan, Bret, I am not the one who proposed to include object_modified nor the one who said
it should be optional, but I understand the rationale behind both of them. I understand that object_modified by is necessary when the object is rewritten substantially (ex. when much better understanding of the attack has been obtained). However, I understand that an object can be updated without changing its text properties, thus making object_modified optional.
(I am not sure my understanding is correct. Please add/comment on it.) > I think a simple statement saying that a consumer can ignore this optional property if it so chooses is fine. I think that this (mentioning a consumer can ignore this optional property) is up to the implementers and that this may be part of interoperability documents, not standard documents. I believe that the standard document should make very clear the meaning and/or rationale behind the decision (ex. why it is decided optional, not required) and that we should leave how to deal with it to the implementers. Regards, Ryu From:
cti@lists.oasis-open.org [mailto:cti@lists.oasis-open.org]
On Behalf Of Allan Thomson Although I prefer that this property be removed completely, in the spirit of making progress towards closing down 2.1 specification -> I’m fine making this property optional. As with any optionally defined features we should be clear on what is means to a consumer when receiving content that has this property defined but the consumer either does not have the version of object referenced nor
cares about the version but rather just the object itself (regardless of version). I think a simple statement saying that a consumer can ignore this optional property if it so chooses is fine. Allan From:
"cti@lists.oasis-open.org" <cti@lists.oasis-open.org> on behalf of Bret Jordan <Bret_Jordan@symantec.com> All, We have several topics to address tomorrow during the working call. The most notable is a change to the Language Content object. The change being proposed is to make the "object_modified" property optional instead of required. This will still allow organizations to pin a translation to a specific version, but will also allow organizations to
say the translation should be good for all versions. If you have an opinion on this topic, please either send it to the email list or join the call tomorrow. Thanks, Bret |
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]