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] Issues


I see where you're coming from. And sticking with the subFs would be comfortable for me because it isolates me from my discomfort with escaping XML (btw, a friend just sent me a great article on the evils of escaping XML in and XML vocabulary, happy to share it with anyone interested). I think we come close to that boo boo here, but do not commit it.

So as long as we take care to not allow overloading, we gain one big advantage by killing the subFs and adding attribute values to ride along with fs. We can allow more than one attribute.

<img src="smileface.png alt="smile" />

fs:fs="img src='smileface' alt='smile'"

In my mind this broadens the power of fs without too badly overloading it.

- Bryan
________________________________
From: xliff@lists.oasis-open.org [xliff@lists.oasis-open.org] on behalf of Dr. David Filip [David.Filip@ul.ie]
Sent: Friday, April 12, 2013 1:50 PM
To: Schnabel, Bryan S
Cc: Yves Savourel; xliff@lists.oasis-open.org
Subject: Re: [xliff] Issues

I do not know now, this seems a quite radical change, why not just stay with IRI for subFs for now?
This is human readable, largely protected from overloading..
I think that anything else is an overkill, you basically talk about way of providing a source URL for an image, so why complicate things..
Other stuff needs to be fixed before Tuesday..

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
mailto: david.filip@ul.ie<mailto:david.filip@ul.ie>


On Fri, Apr 12, 2013 at 9:15 PM, Schnabel, Bryan S <bryan.s.schnabel@tektronix.com<mailto:bryan.s.schnabel@tektronix.com>> wrote:
Yes. Absolutely. That's exactly what I had in mind. It helps to enforce what I think of as two important design goals  we've talked about.

1. The fs attribute is for hints about formatting a just-in-time, in context HTML review. It MUST not be used as a devise to prescribe a round trip.

2. The fs attribute should be simple, and comprehensible by a human. (this is subjective for sure, but I think a reasonable design goal).

I think limiting the fs to a single HTML element will prevent really ugly overloading, like trying to escape an entire complex table into a single fs attribute. Elements with content would be an even worse abuse of the design goals.
________________________________________
From: xliff@lists.oasis-open.org<mailto:xliff@lists.oasis-open.org> [xliff@lists.oasis-open.org<mailto:xliff@lists.oasis-open.org>] on behalf of Yves Savourel [ysavourel@enlaso.com<mailto:ysavourel@enlaso.com>]
Sent: Friday, April 12, 2013 1:03 PM
To: xliff@lists.oasis-open.org<mailto:xliff@lists.oasis-open.org>
Subject: RE: [xliff] Issues

> I'll take it even further, what value does the "&lt;"
> and the ">" add? It is clear in the spec that we're
> talking about HTML elements.
>
> Why not fs="img src='smileface.png'" ?

With that notation you would lose the capability to set several elements, or elements with content.
Not sure if this is something you wish to have or not.

cheers,
-yves




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