Re: [xliff] <reformat> element

["Matthew.Lovatt" <Matthew.Lovatt@oracle.com>]

Thanks for the Feedback Yves

Can i make a few responses
----------------------------------------------------------------------------
--------------------------------------------
New Issue: Font and Coord attributes are not well defined

[YS: I agree on 'not well defined' and would expend that comment to menu,
menu-option, style, exstyle, css-style, etc., basically all the attributes
that carry information that are only "borderline generic".]

ML Agreed: I gave font and coord as examples. Note that even with the two
exampes given we are not consistent in delimeter character: font uses colon,
coord useess semicolon

Discussing this document with other developers has raised some concern over
the format of attributes such as font and coord. These attributes contain
multiple values with delimiting characters.
Since these structures appear in free form text within the attribute, it is
impossible to validate that they are structured correctly.

[YS: XML Schema allows (at least to some extend) to validate such content
using pattern and regular-expression
(http://www.w3.org/TR/xmlschema-2/#regexs).]

ML: I feel that breaking the attribute up will be simpler and safer than
reg-ex's, but i am open to persausion
 ---------------------------------------------------------------------------
---------------------------
Individual members of an element mat be controlled using attribute
<reformat attribute =”coord:cx” edit=”true”/>
[YS: Maybe using @ for attribute separator would be better, as ':' maybe
used for namespace?]
ML Agreed:
[YS: Maybe using XPath expression would be better?]
ML I will investigate this:

[YS: Suggestion maybe (not sure if it's a good idea: Maybe the first
parameter could have several items listed (<reformat element="coord style
exstyle" edit="yes"/> so only one <reformat> element could be used for
several items)?]
ML Agreed:
 ---------------------------------------------------------------------------
---------------------------
[YS: Do we need an element for coord. the same result would be done with
having c, y, cx, and cy as attribute instead of the coord attribue]
ML: This also applies to any structured attribute. Should we break up each
structured attribute into its indivisual member?
 ---------------------------------------------------------------------------
---------------------------

[YS: Don't we have a naming convention policy about lowercase names?]
ML: Yes,  i was thinking in Java - Sorry
 ---------------------------------------------------------------------------
---------------------------
[YS: I would argue that this is a Windows-specific set of value. For example
XML data would often use CSS-type font descriptions where there are many
more information (http://www.w3.org/TR/REC-CSS2/fonts.html) this culd be
handle by css-style attribute, but then why having 2 ways to specify font?
This leads back to the question that maybe some attribute are too specific
to be part of XLIFF core (?) and should have their own namespace.]

ML: Not really windows specific, I based that discussion on
http://www.w3.org/TR/REC-CSS1

 ---------------------------------------------------------------------------
---------------------------

[YS: maybe for the edit attribute: "yes" "no" rather than "true" and "false"
to be consistent with other Boolean attributes we already have?]

ML: AGREED - My Mistake

 ---------------------------------------------------------------------------
---------------------------
Cascading Inheritance
ML: the reformat element is getting dangerously close to the notion of
sending processing instructions to the XLIFF tool!
I didn't realy think of it in terms of validation
Any Thoughts?


Mat

----- Original Message -----
From: "Yves Savourel" <ysavourel@translate.com>
To: "XLIFF list" <xliff@lists.oasis-open.org>
Sent: Thursday, July 11, 2002 12:00 AM
Subject: [xliff] <reformat> element


> Hi everyone,
>
> Here are a few notes on Matt's proposal for the <reformat> element. I like
> the general idea: it makes things flexible. The main concern I have is
about
> the amount of additional data we would have to put in the file. I've added
> my notes in yellow in Matt's original file (see attachement).
>
> cheers
> -yves
>
>
>