RE: [xliff] Working Draft

[Yves Savourel <ysavourel@translate.com>]

Hi John,

Thanks a lot for all the thorough comments.
I'll integrate them after next weeks meeting.

One interesting point you raised was the attributes with list of values.
We definitely need to clarify this. I had the understanding (possibly
incorrect) that all attributes with an enumeration of "recommended values"
in 1.0 were to be converted into a formal externalized enumerated list (with
XSD), that could be either closed or opened. But (if I understand well) your
understanding is that some of them are "free-style" values. I guess the
difference is not apparent when just using DTD, but needs to be clarified
with XSD.
I guess we need to go through them one by one and make decide exactly what
they should be in 1.1: xsi:string, enumerated closed lists, or enumerated
extensible lists.

Have all a great week-end.
-yves



-----Original Message-----
From: John Reid [mailto:JREID@novell.com]
Sent: Tue, July 16, 2002 4:41 PM
To: xliff@lists.oasis-open.org
Subject: Re: [xliff] Working Draft


Hi Yves,

Thanks for all the work. My comments on the working draft follow. First
though, a general comment: The color scheme allows for text that is
added and deleted but doesn't differentiate between those sections that
are agreed upon and those still under discussion. Since some of the
proposals that are still under discussion have been included in this WD
it seems only appropriate that they are marked in some way to indicate
their possible validity.

1. In the table of contents under "Appendices" appendix B is changed
from "Document Type Definition for XLIFF" to "XML Schemas for XLIFF"
However, we decided not to get rid of DTDs. Thus Appendix B should still
reference that. The other should be a new appendix.

2. In section 1.1.1. rule 4, "Some names may be not hyphenated if they
correspond to an existing convention in the industry (e.g. datatype)",
has been added. However, this rule is unnecessary since "may" used in
rule 3 only permits the use but does not require it. Rule 4 is also
covered by rule 7.

3. In section 1.1.1. rule 5 has been changed from
"Elements and attributes should not have the same name, even attributes
of different elements."
to
"Elements and attributes should not have the same name, including
attributes of different elements if the have a different semantic."

Previously, rule 5 said that an attribute must not have the same name
as an element and vice versa. Thus, as it stands now, tool, reformat,
font, and coord cannot be the names of elements since they are already
attribute names. It may be ambiguous as to whether attributes of
different elements can have the same name. I always interpretted it as
allowing attributes to be named the same. I think the proposed change is
just as ambiguous. Maybe it should be "An attribute cannot have the same
name as an element nor can an element have the same name as an
attribute." Of course the latter phrase is unnecessary.

Rule 6 was meant to address the concept of requiring attributes of the
same name to have the same semantics. Maybe, rule 6 should be
"Attributes of the same name must have the same semantics." However,
does this force on us the variants of 'type' that we have?

4. In section 2.3 the following has been added, "Note that the
<prop-group> has been deprecated in version 1.1." Shouldn't we simply
remove this paragraph (to a Deprecated section)? Or find a scheme of
marking deprecated sections?

5. In section 2.4.1 and later under a number of elements the child
elements are still unordered. Didn't we decide to fix their order and
make that consistent. Something like:

 For <header>
 zero or one <skl> followed by
 zero or one <phase-group> followed by
 zero, one or more <glossary> followed by
 zero, one or more <reference> followed by
 Zero, one or more <count-group> elements followed by
 Zero, one or more <prop-group> elements followed by (deprecated)
 Zero, one or more <note>

 For <group>
 Zero, one or more <context-group> elements followed by
 Zero, one or more <count-group> elements followed by
 Zero, one or more <prop-group> elements followed by (deprecated)
 Zero, one or more <note> elements followed by
 At least one of <group>, <trans-unit>, <bin-unit> elements in any
order.

 For <trans-unit>
 One <source> element followed by
 Zero or one <target> elements followed by
 Zero, one or more <alt-trans> elements
 Zero, one or more <context-group> elements followed by
 Zero, one or more <count-group> elements followed by
 Zero, one or more <prop-group> elements followed by (deprecated)
 Zero, one or more <note>

 For <alt-trans>
 Zero or One <source>, followed by
 One or more <target>, followed by
 Zero, one or more <context-group> elements followed by
 Zero, one or more <prop-group> elements followed by (deprecated)
 Zero, one or more <note>

 For <bin-unit>
 One <bin-source> element followed by
 Zero or one <bin-target> elements followed by
 Zero, one or more <context-group> elements followed by
 Zero, one or more <count-group> elements followed by
 Zero, one or more <prop-group> elements followed by (deprecated)
 Zero, one or more <note> elements followed by
 Zero, one or more <trans-unit>

This would fix the location of the extension points a little tighter
than described in 2.4.1.

6. Also, note the inconsistent capitalization of "Zero" and "One",
above. I copied those lines from the WD. I think this inconsistency has
been around since the earliest draft of 1.0.

7. In section 2.4.1 - Yes. I think we need to allow for multiple
extended elements for the reason you've provided.

8. In section 3.1, again references to DTDs and the DOCTYPE declaration
are deleted. Shouldn't we have this info in there for DTDs, since they
are still being supported?

9. In section 3.1, the link for "Validating Documents with Extensions"
doesn't work right.

10. In section 3.2.2 under <count>, "A list of recommended values for
count-type and unit is provided by the specification" has been replaced
by "A list of values for count-type and unit is provided in the XLIFF
Values schema." This change occurs in quite a few spots in the WD.
However, we have not decided to enumerate any of these lists. The
recommendations are still valid. Attributes where this change has
occured:
 count-type
 unit
 datatype
 restype
 size-unit
 context-type
 ctype
 mtype
 state

11. Under "—- work notes —-", there are references to my
disagreement on naame changes of attributes. These are very accurate but
give the impression I am the lone dissenter. However, we have agreed as
a group that there will be no name change to an element or attribute
without a corresponding semantic change. This is in direct response to
the proposed changes referenced here. Thus, the comment is misleading
and the possible inclusion in 1.1 of these changes has already been
decided in the negative.


cheers,
john


----------------------------------------------------------------
To subscribe or unsubscribe from this elist use the subscription
manager: <http://lists.oasis-open.org/ob/adm.pl>