Thanks Bryan, in the interest of keeping just one metadata element at the allowed extension point as already defined in the spec, we would advocate #2, adding
a <metagroup> element. Thanks for adding the roll call vote to the next call.
ryan
From:
xliff@lists.oasis-open.org [mailto:
xliff@lists.oasis-open.org]
On Behalf Of Schnabel, Bryan S
Sent: Wednesday, November 28, 2012 12:43 PM
To: Rodolfo M. Raya;
xliff@lists.oasis-open.org Subject: RE: [xliff] Metadata Grouping <was: RE: [xliff] 1.2 to 2.0 Gaps and Proposals (metaData)>
Ryan, Rodolfo, all,
I agree that the three choices are clear, and have been robustly debated. For example, based on what I’ve seen of the debate I would choose option 1.
I think it is really too late to have an electronic ballot since the next meeting is less than a week away.
I am grateful to all on this thread for the excellent and thorough debate. I would ask all of us to provide any “closing arguments” so that we can vote on this
as a role call ballot early in our next meeting.
Thanks,
Bryan
From:
xliff@lists.oasis-open.org [ mailto:
xliff@lists.oasis-open.org ]
On Behalf Of Rodolfo M. Raya
Sent: Wednesday, November 28, 2012 12:13 PM
To:
xliff@lists.oasis-open.org Subject: RE: [xliff] Metadata Grouping <was: RE: [xliff] 1.2 to 2.0 Gaps and Proposals (metaData)>
At least be polite and wait until I leave the TC in December before asking Bryan for that ballot. I designed current metadata module (XML schema and documentation),
not Bryan.
Regards,
Rodolfo
--
Rodolfo M. Raya
rmraya@maxprograms.com Maxprograms
http://www.maxprograms.com From:
xliff@lists.oasis-open.org [ mailto:
xliff@lists.oasis-open.org ]
On Behalf Of Ryan King
Sent: Wednesday, November 28, 2012 6:05 PM
To: Rodolfo M. Raya;
xliff@lists.oasis-open.org ; Schnabel, Bryan S (
bryan.s.schnabel@tektronix.com )
Subject: RE: [xliff] Metadata Grouping <was: RE: [xliff] 1.2 to 2.0 Gaps and Proposals (metaData)>
Ugly is in the eye of the beholder
J . I think the below example is less readable and less structured, and using a <metagroup> is still
a relatively simple XML structure.
<mda:metadata>
<meta type="previous-source" group=”properties”>hello world</meta>
<meta type="string-category" group=”properties”>TextBox</meta>
<meta type="workorder-id" group=”properties”>25</meta>
<meta type="workorder-name" group=”properties”>Hotmail</meta>
<meta type=”boundingbox” group=”screencapture”>20,20,10,15</meta>
<meta type=”uri” group=”screencapture”>imagessignuplogin.jpg</meta>
<meta type=”hash-id” group=”screencapture”>tc22457</meta>
</mda:metadata>
In any case, Bryan, as current owner of <mda:metadata>, do you feel we need to put this to electronic ballot at this point to choose between the three proposed implementations?
1.
More than one <mda:metadata> with a name attribute at the extension point
2.
One <mda:metadata> at the extension point with a <metagroup> element
3.
One <mda:metadata> at the extension point with a group attribute on <meta>
Thanks all for the discussion,
Ryan
From:
xliff@lists.oasis-open.org [ mailto:
xliff@lists.oasis-open.org ]
On Behalf Of Rodolfo M. Raya
Sent: Wednesday, November 28, 2012 11:51 AM
To:
xliff@lists.oasis-open.org Subject: RE: [xliff] Metadata Grouping <was: RE: [xliff] 1.2 to 2.0 Gaps and Proposals (metaData)>
Still ugly.
Add a “group” attribute to <meta> and you will be able to do what you want with a much simpler design.
Regards,
Rodolfo
--
Rodolfo M. Raya
rmraya@maxprograms.com Maxprograms
http://www.maxprograms.com From:
xliff@lists.oasis-open.org [ mailto:
xliff@lists.oasis-open.org ]
On Behalf Of Ryan King
Sent: Wednesday, November 28, 2012 4:30 PM
To: Estreen, Fredrik; Rodolfo M. Raya;
xliff@lists.oasis-open.org Subject: [xliff] Metadata Grouping <was: RE: [xliff] 1.2 to 2.0 Gaps and Proposals (metaData)>
We are primarily concerned with being able to group related pieces of metadata, so Fredrick’s alternative methods would give us the same result and allow us
to keep one <metadata> at each extension point. We would prefer a more structured approach. How is this for example:
<mda:metadata>
<metagroup
name=”properties” >
<meta type="previous-source">hello world</meta>
<meta type="string-category">TextBox</meta>
<meta type="workorder-id">25</meta>
<meta type="workorder-name">Hotmail</meta>
</metagroup>
<metagroup
name=”screencapture” >
<meta type=”boundingbox”>20,20,10,15</meta>
<meta type=”uri”>imagessignuplogin.jpg</meta>
<meta type=”hash-id”>tc22457</meta>
</metagroup>
</mda:metadata>
Thanks,
Ryan
From:
xliff@lists.oasis-open.org [ mailto:
xliff@lists.oasis-open.org ]
On Behalf Of Estreen, Fredrik
Sent: Wednesday, November 28, 2012 4:46 AM
To: Rodolfo M. Raya;
xliff@lists.oasis-open.org Subject: RE: [xliff] 1.2 to 2.0 Gaps and Proposals (metaData)
Hi Rodolfo, Ryan,
I definitely see a value in being able to group the meta data. Both for display and processing purposes. For display it allows more natural names without breaking
the ability to easily order / group values relating to each other. For processing it makes it easier to add/remove a set of metadata for a tool or tool feature. It also reduces the risk of name clashes for the key.
I’m not convinced allowing multiple <metadata> elements at the same level is the direction to go tough. I can see two other solutions, either grouping the metadata
items through a new element inside <metadata> or through an additional attribute on the <meta> element. Both solutions have pros and cons. Personally I prefer the more structured way with grouping by elements, but implementation wise it is probably easier
to group by attributes. The later way also solves the issue with users that do not want groups, if the new attribute is optional and any <meta> without it is considered part of an anonymous group.
Regards,
Fredrik Estreen
From:
xliff@lists.oasis-open.org [ mailto:
xliff@lists.oasis-open.org ]
On Behalf Of Rodolfo M. Raya
Sent: den 28 november 2012 09:31
To:
xliff@lists.oasis-open.org Subject: RE: [xliff] 1.2 to 2.0 Gaps and Proposals
Still a bad use case that doesn’t justify ruining a good design.
Regards,
Rodolfo
--
Rodolfo M. Raya
rmraya@maxprograms.com Maxprograms
http://www.maxprograms.com From:
xliff@lists.oasis-open.org [ mailto:
xliff@lists.oasis-open.org ]
On Behalf Of Ryan King
Sent: Wednesday, November 28, 2012 5:46 AM
To: Rodolfo M. Raya; Schnabel, Bryan S; <
xliff@lists.oasis-open.org >
Subject: RE: [xliff] 1.2 to 2.0 Gaps and Proposals
So that our original reason for proposing having more than one <mda:metadata> at the extension point does not get obfuscated in all of the replies and “see
inlines”, here once again, is the use case for adding more than one <mda:metadata> per extension:
Proposal 4: Add an optional name attribute on <notes> in core and <mds:metadata> module.
We believe it will be typical for content providers to want to group their notes or metadata in meaningful ways. This might be done so that a certain number of notes or bits of metadata can be processed in the same way, or simply grouped
and displayed together, such as in an editor UI. Here are some examples:
<mda:metadata
name=”properties” >
<meta type="previous-source">hello world</meta>
<meta type="string-category">TextBox</meta>
<meta type="workorder-id">25</meta>
<meta type="workorder-name">Hotmail</meta>
</mda:metadata>
<mda:metadata
name=”screencapture” >
<meta type=”boundingbox”>20,20,10,15</meta>
<meta type=”uri”>imagessignuplogin.jpg</meta>
<meta type=”hash-id”>tc22457</meta>
</mda:metadata>
As opposed to something less structured and more difficult to process:
<mda:metadata>
<meta type="properties-previous-source">hello world</meta>
<meta type="properties-string-category">TextBox</meta>
<meta type="properties-workorder-id">25</meta>
<meta type="properties-workorder-name">Hotmail</meta>
<meta type=”screencapture-boundingbox”>20,20,10,15</meta>
<meta type=”screencapture-uri”>imagessignuplogin.jpg</meta>
<meta type=”screencapture-hash-id”>tc22457</meta>
</mda:metadata>
Thanks,
Ryan
From:
xliff@lists.oasis-open.org [ mailto:
xliff@lists.oasis-open.org ]
On Behalf Of Rodolfo M. Raya
Sent: Tuesday, November 27, 2012 5:37 PM
To: Ryan King
Cc: Schnabel, Bryan S; <
xliff@lists.oasis-open.org >
Subject: Re: [xliff] 1.2 to 2.0 Gaps and Proposals
Please do not ruin the design of the metadata module. Only one metadata element is intended to be allowed per extension point.
Regards,
Rodolfo
Sent from my iPad
On Nov 27, 2012, at 9:51 PM, "Ryan King" <
ryanki@microsoft.com > wrote:
Hi Bryan, in last week’s TC call it was mentioned that I should work with the owners of the current features to get our requirements implemented for proposals
that weren’t deemed as features. I believe you are the owner for the metadata module. Can you please let me know what we need to do to move forward with getting this implemented?
·
Proposal 4: Add an optional name attribute on <mda:metadata> module (which also means that we need to allow
zero, one or more <mda:metadata> in each position in the tree structure)
I’m not sure if this requires an electronic ballot. I got the impression from the call that it doesn’t, but hopefully you or David or someone else from the call
will correct that if false.
Please let me know how I can work with you on this.
Ryan
From:
xliff@lists.oasis-open.org [ mailto:
xliff@lists.oasis-open.org ]
On Behalf Of Ryan King
Sent: Friday, November 16, 2012 5:02 PM
To: Dr. David Filip; Yves Savourel;
xliff@lists.oasis-open.org Subject: RE: [xliff] 1.2 to 2.0 Gaps and Proposals
Thanks Yves and David for the valuable feedback. See our comments inline below prefixed with [Microsoft]. As David suggested on another thread, we will add
these soon to the wiki.
From:
xliff@lists.oasis-open.org [ mailto:
xliff@lists.oasis-open.org ]
On Behalf Of Dr. David Filip
Sent: Thursday, November 15, 2012 5:24 PM
To: Yves Savourel
Cc:
xliff@lists.oasis-open.org Subject: Re: [xliff] 1.2 to 2.0 Gaps and Proposals
Yves, Ryan et. al.
Commenting inline..
Cheers
dF
On Thu, Nov 15, 2012 at 8:23 PM, Yves Savourel <
ysavourel@enlaso.com > wrote:
Hi Ryan, all,
> Proposal 1: Add an optional build attribute to 2.0 <file> element in core.
> ..
> <file id=”1” original=”mainUI.resx” build="2011-11-23-133615307_windc.win8.beta.b01">
I don't see anything wrong with this.
> Proposal 2: Be able to specify optional custom values for match type
> attribute in the <mtc:matches> module.
> Content providers and Localization Suppliers base their cost and billing
> models on match similarity and match types. Localization suppliers charge
> us differently for ICE Matches, Exact Matches, and Fuzzy Matches, and we
> might even want to get more granular than that as our cost and billing models
> evolve with the business.
> In 2.0, the match type doesn’t support the values exact-match and fuzzy-match,
> which were defined in the state-qualifier attribute in 1.2. Instead of supporting
> these two, or any others that may not have migrated from 1.2 to 2.0,
> as a separate attribute, the request is, that like the discussion on state
> and sub-state in the Face-to-Face in Seattle, we add a sub-type to match type.
> This will allow us to add extra business logic to types, such as "tm" or "mt",
> which are already defined in the spec.
> <match id=”1” similarity=”100.0” type=”tm/xlf:exact”>
> <match id=”1” similarity=”75.0” type=”tm/xlf:fuzzy”>
> <match id=”1” similarity=”99.0” type=”tm/custom:near-exact”>
I understand the need for the information, but to me, it seems the similarity give you whether a match is exact or not.
The example however, shows (I think) that you are thinking about categories that could be mapped differently to the similarity depending on projects. For example in one project a near-match corresponds to one range and in another to a different range, and you
want to simply map that info to something common across your process, without having to carry the ranges around. If that's the case I wonder if XLIFF should define any default like xlf:exact, etc.
I believe there is value in decoupling the "percentage" from the "business" type of the match. The number means nothing unless we opt to prescribe a specific variety of (modified) Levenshtein, and I i guess we should not open this particular
can of worms..
So I wouldn't see a problem with a sub-type there.
A side comment on the match type: especially, if we allow sub-type, I'm still not sure about the values currently listed.
[Microsoft] we definitely advocate decoupling the “percentage” from the “business” type of match as David puts it. And we should not prescribe meaning to the
percentage, either. Costing models built on top of these values will necessarily change from one provider/supplier to the next and as Yves states, possibly from one project to the next. We could very easily have the following (and we do in much of our recycled
content):
<match id=”1” similarity=”100.0” type=”tm/xlf:exact”>
<match id=”1” similarity=”100.0” type=”ice”>
In the first case, we’ve recycled a candidate which is 100% match, but came from a segment whose state isn’t signed off or final yet, whereas the ice match,
in our case, has the requirement of being 100% and signed off or final.
> Proposal 3: Add an optional Reference Language to core.
> This is a crucial feature for Microsoft and other large companies that localize
> minority languages. For example, it is typical that when we localize from
> English into Quechua, localizers are more efficient and provide much higher
> quality translation, when along with English source, we provide them with
> Spanish target. In 1.2, Reference Languages could be defined in
> an <alt-trans> element:
I see the use case and I've seen other cases like this, with Chinese (simplified/Traditional).
Could that be part of the match module?
Possibly with a new attribute (e.g. reference='yes no' defaulting to no)
Adding something along with <source>/<target> is bound to cause additional PR issues. If it's part of the Match module, it just uses whatever the module PRs are.
I agree with Yves's reasons to have this within the match module, which is anyway the alt-trans successor. I guess it does not fulfill the core criteria
[Microsoft] Adding this to the match module would be fine as long as the proper explanatory text and processing instructions make it clear what this data should
be used for as opposed to recycling.
> Proposal 4: Add an optional name attribute on <notes> in core
> and <mds:metadata> module.
> We believe it will be typical for content providers to want to
> ...
> <notes name="comments">
> <note id=“comment">This string cannot be longer than 100 characters</note>
> <note id=“user">
Developer@microsoft.com </note>
> <note id=“date">10/21/2012 5:28:13 PM</note>
> </notes>
Sounds reasonable. We'll have to allow several <notes> and <m:metadadat> (I think (but I may be wrong) only one is allowed)) on the extension point.
The example makes me wonder about the long term life of XLIFF though: likely this type of info (author, timestamp) will be needed by other. Maybe a better way to address it would be to add attributes to the note and meta that carry the author and time stamp?
That would obviously work only if those two info are the only example you have in mind.
I agree with Yves that a couple of standard attributes should be added to increase interoperability, still I believe that note should be fully extendable, as it is part of the general annotation mechanism and should be able to carry attributes
from other namespaces.
[Microsoft] Capturing an author and timestamp on a comment is specific to our needs and thus that example. However, we do see value in being able to apply an
author and timestamp on potentially any piece of data. So a module (as Yves suggests below) that can exists at the same extension points as metadata (and including metadata) might lend itself better to that.
> Proposal 5: Add optional change tracking attributes to <segment>.
> ...
> <segment id=”1” modifiedBy=”
translator@loc.com ”
> modifiedDate=”10/21/2012 5:28:13 PM”>
> <source>hello world</source>
> <target>hola món</target>
> </segment>
Here again I'm wondering if a "change track" module may be better?
You could use it not just on segments but other elements: notes.
The issue then would be how this gets updated if it's not a core component?
Actually if it's a core attribute, does it means it's not optional?
I'm not sure there is a way, even with a PR, to guarantee these data will be up-to-date.
But maybe that's ok?
Optional attributes in core are tricky, IMHO It means you do not need to introduce it yourself, if you do not feel so.. But if present it would need to be processed by agents who modify the segment. If it is thinkable that change agents
do not update it, it feels more like a module...
[Microsoft] Since we are heading down the same path to MUST preserve modules as well, if we introduce a “change track” module, then user agents would need to preserve it if present,
but as for any other processing requirements, such as updating it, that could be specified as part of the module’s processing requirements. For example: The module MUST be preserved and SHOULD be updated by user agents.
cheers,
-yves
---------------------------------------------------------------------
To unsubscribe, e-mail:
xliff-unsubscribe@lists.oasis-open.org For additional commands, e-mail:
xliff-help@lists.oasis-open.org