RE: [xliff] RE: [xliff-inline] Propose 2 enhancements to @fs

Hi Bryan,

The focus should not be in just images, the "fs" attribute needs to work in any circumstance. The workaround to store image paths is too specific.

Regards,
Rodolfo
--
Rodolfo M. Raya       
Maxprograms       http://www.maxprograms.com

> -----Original Message-----
> From:  [mailto:] On Behalf
> Of Schnabel, Bryan S
> Sent: Monday, October 08, 2012 4:39 PM
> To: Yves Savourel; 
> Subject: RE: [xliff] RE: [xliff-inline] Propose 2 enhancements to @fs
> 
> Hi Yves,
> 
> Ok. Now I’ve got it. (1) Make fs interoperable; (2) Add an fs mechanism to
> store the path of images to render. And presumable doing (2) helps achieve
> (1).
> 
> Maybe we are in violent agreement after all.
> 
> I’m in favor of (1) – and I’m not aware of how anything I said earlier in the
> thread is counter to that, including my observation that some XLIFF will be
> good candidates for fs, and some XLIFF will not (interoperable - ly, across the
> board for all). Example, I cannot imagine my firmware XLIFF files lending
> themselves to a just-in-time browser view facilitated by fs – nothing to do
> with interoperability.
> 
> If you are saying that my attempts to render images via fs, based on non-fs-
> contained information, located elsewhere in an XLIFF file contradicts
> interoperability – I say okay – let’s fix it (which leads us to (2)).
> 
> Regarding (2) – were you just talking about images? Or do we want to  add a
> mechanism to fs to address other potentially tricky browser rendering
> situations as well (like maybe cross references, variables, entities, conrefs,
> OOP . . .)?
> 
> My reason for asking, if it’s just image paths, I agree with you that the
> solution is easy. I have no qualms about, for example, breaking fs into a pair
> of attributes. We could have fs-element and (optionally) fs-path:
> 
>  <segment>
>               <source>Science is <ph id="1" /> good.</source>
>               <target
> fs="p">&#31185;&#23398;&#36824;&#26159;&#19981;&#38169; <ph id="1"
> fs-element="img" fs-path=” big-happy-smile.jpg” />
> &#30340;&#12290;</target>  </segment>
> 
> The only tricky thing I can think of in this case is how to express in XML
> Schema that @fs-path can only exist if @fs-element exits.
> 
> I just wonder how far down the rabbit hole we’d have to go if we tried to
> solve fs issues for every situation (beyond just images) we could think of.
> 
> Eager for more thinking on this topic,
> 
> Bryan
> 
> -----Original Message-----
> From:  [mailto:] On Behalf
> Of Yves Savourel
> Sent: Monday, October 08, 2012 9:30 AM
> To: 
> Subject: RE: [xliff] RE: [xliff-inline] Propose 2 enhancements to @fs
> 
> Hi Bryan, all,
> 
> > Bottom line, I think fs can be used on *some* XLIFF files in *some*
> > situations - but not all XLIFF files for all situations.
> > Our trickiest example so far is images. For this example I would say
> > if the XLIFF file has a clear way of marking up the images, and if
> > rendering images is important for the in context review, then the fs
> > writer (using whatever language to decode and render) has a reasonable
> > hope to present them in a just-in-time browser rendering.
> 
> To me it's not a matter of scope (how much the fs mechanism should allow
> the renderers to do), it's a matter of interoperability (all tools should be able
> to use fs when present). Having a "reasonable hope" to be able to access the
> proper data is not going to work.
> 
> A mechanism that is defined in the XLIFF specification (core or module)
> should not rely on <data> or the skeleton to do something, because the
> specification only define a place where to put the original data.
> 
> 
> > Who knows, reasonable
> > markup could exist in the <data> element, or in the skeleton, or in an
> > external file.
> > But in some cases, where the XLIFF file does not manage the clues
> > about the images, or does so in a way that is beyond the fs levers,
> > then images are simply off the menu.
> 
> Again, this is my point: if you want the fs mechanism to display images in an
> interoperable way, it's easy: add to the fs mechanism a way to store the path
> to the image to render. Then tool generating the fs markup can also provide
> the images (if it's doable), and the mechanism stays interoperable.
> 
> Cheers,
> -yves
> 
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: 
> For additional commands, e-mail: 
>