Guys, Chet, pointed out in another conversation that the comment list is
not intended for discussions.
This discussion either has to happen between Ryan and Josep and Ryan can
update the TC on the result.
Or, Josep, we cordially invite you to join the TC :-) and continue the
discussion on the TC list
Rgds
dF
David Filip, Ph.D.
=====================
*cellphone: +353-86-0222-158*
mailto:
davidf@davidf.orgwww.davidf.org, http://www.linkedin.com/in/davidfatdavidf
On Thu, May 30, 2013 at 7:32 PM, Ryan King <
ryanki@microsoft.com> wrote:
> Thank you Josep for pointing this out. I agree with your logic on this
> point. In my original example, tools aware of xy:sourceUpdate could alert a
> translator to review and possibly re-translate the segment whether the
> state is translated or initial. However, tools not aware of xy:sourceUpdate
> would need to rely on state alone, and therefore, your example makes more
> sense here.****
>
> ** **
>
> *From:* Josep Condal [mailto:
pcondal@apsic.com]
> *Sent:* Thursday, May 30, 2013 11:21 AM
> *To:* Ryan King; David Filip; Yves Savourel
> *Cc:*
xliff-comment@lists.oasis-open.org>
> *Subject:* RE: [xliff-comment] XLIFF 2.0 Comments - B.1.3.7 subtype
> processing requirements****
>
> ** **
>
> Ryan,****
>
> ****
>
> An unrelated comment to this thread (but I think that yet important to
> point out) is that for the second handoff, the logical state of the changed
> segment should be reverted back to "initial", regardless of if <target> is
> primed with something potentially useful (or not) for the translator. ***
> *
>
> ****
>
> Otherwise it will not be possible for a tool to tell if it makes sense to
> consider the segment as really translated or not. Please note that there
> are no differences in attributes for the first two stages of the second
> handoff, and tools cannot (yet) understand natural language well enough
> to infer the state of the segment in the same way a human being could do it.
> ****
>
> ****
>
> <segment state=”*initial*” subState=”xy:sourceUpdate”>****
>
> hello world****
>
> <target>halló</target>****
>
> </segment>****
>
> ****
>
> Regards,****
>
> Josep.****
>
> ****
>
> ** **
> ------------------------------
>
> *De:* Ryan King [mailto:
ryanki@microsoft.com <
ryanki@microsoft.com>]
> *Enviado el:* jueves, 30 de mayo de 2013 19:15
> *Para:* David Filip; Yves Savourel
> *CC:*
xliff-comment@lists.oasis-open.org> *Asunto:* RE: [xliff-comment] XLIFF 2.0 Comments - B.1.3.7 subtype
> processing requirements****
>
> >> 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”>****
>
> hello****
>
> </segment>****
>
> ** **
>
> <segment state=”translated”>****
>
> hello****
>
> <target>halló</target>****
>
> </segment>****
>
> ** **
>
> Second handoff:****
>
> ** **
>
> <segment state=”translated” subState=”xy:sourceUpdate”>****
>
> hello world****
>
> <target>halló</target>****
>
> </segment>****
>
> ** **
>
> <segment state=”translated” subState=”xy:sourceUpdate”>****
>
> hello world****
>
> <target>halló veröld</target>****
>
> </segment>****
>
> ** **
>
> <segment state=”reviewed” subState=”xy:sourceUpdate”>****
>
> hello world****
>
> <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 <
davidf@davidf.org>]
> *Sent:* Thursday, May 30, 2013 5:02 AM
> *To:* Yves Savourel; Ryan King
> *Cc:*
xliff-comment@lists.oasis-open.org> *Subject:* Re: [xliff-comment] XLIFF 2.0 Comments - B.1.3.7 subtype
> processing requirements****
>
> ** **
>
> 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.
> =====================
> *cellphone: +353-86-0222-158*
> mailto:
davidf@davidf.org****
>
>
www.davidf.org, http://www.linkedin.com/in/davidfatdavidf****
>
> ** **
>
> 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]
> *Sent:* Wednesday, May 29, 2013 11:19 AM
> *To:* Yves Savourel;
xliff-comment@lists.oasis-open.org****
>
>
> *Subject:* RE: [xliff-comment] XLIFF 2.0 Comments - B.1.3.7 subtype
> processing requirements****
>
> ****
>
> 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 <
yves@opentag.com>]
> *Sent:* Wednesday, May 29, 2013 3:47 AM
> *To:*
xliff-comment@lists.oasis-open.org> *Subject:* RE: [xliff-comment] XLIFF 2.0 Comments - B.1.3.7 subtype
> processing requirements****
>
> ****
>
> 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 <
ryanki@microsoft.com>]
> *Sent:* Wednesday, May 29, 2013 2:05 AM
> *To:*
xliff-comment@lists.oasis-open.org> *Cc:*
xliff@lists.oasis-open.org> *Subject:* [xliff-comment] XLIFF 2.0 Comments - B.1.3.7 subtype
> processing requirements****
>
> ****
>
> 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****
>
> ****
>
> ****
>
> ** **
>