[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [xliff-comment] XLIFF 2.0 Comments - B.1.3.7 subtype processing requirements
Sorry for the cut and paste typo below: ms:sourceUpdate and xy:sourceUpdate are intended to be the same property, I just want to make sure I don’t introduce confusion. From: Ryan King [mailto:ryanki@microsoft.com]
>> If you cannot update, you MUST drop.. *Something* MUST be done to subproperty if property changed.. I’m not totally convinced that it MUST be dropped. As an example: First handoff: <segment state=”initial”> <source>hello</source> </segment> <segment state=”translated”> <source>hello</source> <target>halló</target> </segment> Second handoff: <segment state=”translated” subState=”xy:sourceUpdate”> <source>hello world</source> <target>halló</target> </segment> <segment state=”translated” subState=”xy:sourceUpdate”> <source>hello world</source> <target>halló veröld</target> </segment> <segment state=”reviewed” subState=”xy:sourceUpdate”> <source>hello world</source> <target>halló veröld</target> </segment> If I understand ms:sourceUpdate, I could clear subState after setting the state to “reviewed”, however, if I don’t understand ms:sourceUpdate, couldn’t I treat it like any
other extension (it is after all a type of extensibility) and just ignore it but preserve it? It could very well be that the content provider that owns xy:sourceUpdate wants to know that a particular handed-back <segment>, which was updated, was indeed re-translated
and reviewed. The advantage to a xlf:subState over some arbitrary extension such as xy:subState is that editors, for example, could relate it and display it with xlf:state in a consistent manner because Processing Instructions state: If the attribute subtype
is used, the attribute type must be specified as well. From: David Filip [mailto:davidf@davidf.org]
I think the update/drop of sub* should be enforced throughout the sub* attributes.. If you own the subtype, it is easy to know the invisible update, I would not be worried with that. The PR is important to those who do not know the predefined subproperties. If you cannot update, you MUST drop.. *Something* MUST be done to subproperty if property changed.. David Filip, Ph.D. On Wed, May 29, 2013 at 7:15 PM, Yves Savourel <yves@opentag.com> wrote: I tend to agree. From: Ryan King [mailto:ryanki@microsoft.com]
All of the sub properties already have the a similar PR to the following: ·
If the attribute subtype is used, the attribute type must be specified as well. So if your statement “I think this PR comes from the constraint that you should not have a subtype without a type, therefore the subtype is linked to
the type (it complements it).” applies to subType in <mtc:matches> shouldn’t it also apply to all sub attributes: 2.3.1.34 subType, 2.3.1.35 subState, D.1.2.2 subFs? I think it should be all or nothing to avoid confusion, or maybe just the PR noted above is
enough to show the relationship? Ryan From: Yves Savourel [mailto:yves@opentag.com]
I think this PR comes from the constraint that you should not have a subtype without a type, therefore the subtype is linked
to the type (it complements it). In your example, if a type can have the same subtype value you can have an “invisible” update: the updated subtype value simply
happens to have the same value as before. -ys From: Ryan King [mailto:ryanki@microsoft.com]
B.1.3.7 subtype processing requirements state: If the attribute type is modified, the attribute subtype must be updated or deleted. Is this always the case? What if I have a two types, e.g. “tm” and “mt”, that have the same subType? If my type changes from “tm” to “mt” there may be
no reason for me to update or delete the subState. Was there a particular reason for this processing requirement? Similar sub attributes… 2.3.1.34 subType 2.3.1.35 subState D.1.2.2 subFs …do not have this requirement. Thanks, Ryan |
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]