OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

xliff message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: Re: [xliff] Call for dissent: 108 Format Style attributes again (RE: [xliff] RE: csprd02 108: (re: Format Style attributes again))


This sounds good to me, just to double check
fs remains on <note>, is just removed from <notes> that groups them..
Are you going to implement this in spec?
Cheers
dF

Dr. David Filip
=======================
LRC | CNGL | LT-Web | CSIS
University of Limerick, Ireland
telephone: +353-6120-2781
cellphone: +353-86-0222-158
facsimile: +353-6120-2734
http://www.cngl.ie/profile/?i=452
mailto: david.filip@ul.ie


On Wed, Nov 13, 2013 at 6:21 PM, Schnabel, Bryan S <bryan.s.schnabel@tektronix.com> wrote:
Yves,

Thank you for your clear explanation. I tried to find the email where I sent what I thought was a compelling reason to retain FS on notes, but as I reread it, in light of your comment that notes and originalData are not part of the XLIFF structure (especially from a preview point of view), my use case seems less relevant.

Given my better understanding, I now propose that we remove @fs and @subFs from <notes>, <originalData>, and <data>.

If I do not hear dissent by the end of the week I will consider this approved.

Thanks,

Bryan

-----Original Message-----
From: xliff@lists.oasis-open.org [mailto:xliff@lists.oasis-open.org] On Behalf Of Yves Savourel
Sent: Wednesday, November 13, 2013 4:04 AM
To: xliff@lists.oasis-open.org
Subject: [xliff] RE: csprd02 108: (re: Format Style attributes again)

Hi Bryan, all,

> I think there is value in keeping the FS module attached to the
> <notes> element (I think I sent an example in an earlier mail).
> But I agree that it should be removed from the <originalData> element.

The problem with <notes> is that, like <originalData> it's an artificial XLIFF structure. By that I mean that it doesn't need to exist from the core data model viewpoint. Its sole function is to group <note> elements: It's syntactic sugar. And therefore it doesn't have necessarily a counterpart when you map the XLIFF data to a tool's data model.


> Yves, could you please provide criteria for when it is too complicated
> or expensive to preserve FS attributes on <data>?

My opinion is not as strong for <data>. It's related to the way my implementation does the mapping:

The Okapi library does not know specifics about modules/extensions but allows the caller to preserve and manipulate them.

The drawback of that is that the code to store an extension is more expensive than just a string. So I'm being a bit wary about any place where I see fs:fs/fs:subFs being the sole reason to have an extension point (from the library viewpoint the FS module is an
extension) on an element that, in real-life documents, may have thousand of occurrences.

In other words I'm weighing the cost vs the utility. And (from my viewpoint) in the case of fs on <data> the cost looks quite high and the utility quite low.

Cheers,
-ys




---------------------------------------------------------------------
To unsubscribe from this mail list, you must leave the OASIS TC that generates this mail.  Follow this link to all your TCs in OASIS at:
https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php




---------------------------------------------------------------------
To unsubscribe from this mail list, you must leave the OASIS TC that
generates this mail.  Follow this link to all your TCs in OASIS at:
https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php




[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]