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: Call for dissent: 108 Format Style attributes again (RE: [xliff] RE: csprd02 108: (re: Format Style attributes again))


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.



-----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.


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:

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