[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: 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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]