|
Tel
: (353)-1-708 2817 |
|
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: [xliff] Xliff Teleconference Minutes - 11 Feb '02
Tony Jewtushenko, Oracle
Corporation, TC Chair
Yves Savourel, TC Editor
Doug Domeny
Mirek Driml,
Moravia-IT
Milan Karásek, Moravia-IT
Christian Lieske, SAP
Mat Lovatt,
Oracle
Enda McDonnell
David Pooley, SDL
John Reid, Novell
Shigemichi
Yazawa
Mark Levins,
IBM/Lotus
Bryan Schnabel, Tektronix
Peter
Reynolds, Bowne Global Solutions, TC Secretary
Mark
motioned to accept Minutes from last week, Shigamichi seconded the
minutes
3.1 Validation of XLIFF 1.0 with 1.1 Schema
Summary
The point here is that
(from Doug’s
mail) ‘The XLIFF 1.1 schema (Draft 3) specifies a
targetNamespace, that is,
targetNamespace="urn:oasis:names:tc:xliff:document:1.1".’
So, a 1.0 document which does
not have this 1.1 namespace declared within, will not be a valid 1.1
document. Currently, no 1.0
document has this 1.1 namespace within, so none will be valid 1.1
documents.
Discussion
Tony pointed out some
discussion on this both from the OASIS
namepsace guidelines and from Christian’s
mail.
John suggested
that we have no option but to go with what Doug indicated in his mail, i.e.
suggest that if people with xliff 1.0 documents wish for them to be valid 1.1
documents, they must change the namespace declaration in the 1.0 file from
Either no declaration OR
xmlns="urn:oasis:names:tc:xliff:1.0"
to
NtargetNamespace="urn:oasis:names:tc:xliff:document:1.1
OutcomeDoug suggested that we include a section ‘helpful tips on how to migrate from 1.0 to 1.1’
IT will be stated in this section that in order to have xliff 1.0 documents validated against the xliff 1.1 schema, the 1.1 namespace will have to be declared.
3.2 Co-ords for <bin-unit> ?
Summary
John Reid discovered a need to specify co-ords of an icon for example in a dialog. However, this is a <bin-unit> and does not have co-ord attributes. As per his mail, John would like to see coord, size-unit, maxheight, minheight, maxwidth and minwidth as attribs of <bin-unit>. Where these items could then be controlled using the reformat mechanism.
Discussion
Mark is
worried
that this assumes that the bin-unit is being assumed to be a graphic in a
dialog. Also how should other
binary units be handled, say the bin-unit is a wave file, it may have its own
attributes that need editing, but these are not supported.
John
agreed that the need for coord, etc. are specific to the instance of a graphic
on some kind of form.
Mark is
against refining the <bin-unit> element at this
point.
John suggested that an alternative would be
to allow a bin-unit in the trans-unit.
This would allow graphics to have co-ord info.
Mark
queried - What about numerous
translation information without having to specify the binary graphic each
time?
Yves
handles this situation by putting the
bin-unit somewhere in the doc and then a trans-unit references those from
somewhere else in the doc.
Yves said the tool would know what to do and how to find the
binary objects.
John says
this is not very interoperable.
Mat
suggests that we could link bin-units and trans-units by giving them the same id
Yves - the
NMTOKEN definition of the 1.0 schema would allow this.
Yves,
John,
The main
problem is that we need a mechanism within the spec for referencing another
unit, i.e. reference a <bin-unit> from a
<trans-unit>
Outcome
John will
formally write and suggest how we could allow referencing in this way. There may be a tu-ref and a bu-ref
attribute that allow trans-units and bin-units to linked through their
ids.
3.3 Attribute Value Naming Convention
Yves pointed out in his mail that at last weeks meeting it was suggested that the guidelines for using lowercase in the attribute values be removed. Because the spec currently states ‘Attribute values are case sensitive. It is strongly recommended that lower-case values are used. The specification recommends a number of values for some attributes, these are all lower-case.’, we probably need to vote on any change to the guidelines.
The
discussion broadened into a number of points
Attribute
names – what case?
Attribute
values – what case?
Attribute
values – allow white space?
John
suggested that we remove the word ‘strongly’ from the
spec.
Mark
suggested we have no whitespaces in attribute values, but allow
CamelCasing. A space for example,
as per his previous proposal, is considered a delimiter in attribute
values.
It was
pointed out that we must also abide by our guideline and that it should also
apply to the x-somename attributes.
Tony -
would like to get rid of whitespace in attribute names and values, otherwise
there is confusion. Not worried
about capitalisation. Shouldn't
have different naming conventions for enumerated lists and extended
lists.
Christian
queried whether we have an issue for backward compatibility with the new naming
convention
John
pointed out that where an attribute’s content definition in spec is defined as
‘text’ - 1.0 docs may very well have whitespace.
1. Keep lower case for the attribute names
- no objections
2. Remove the word 'strongly' from
spec - because where attribute
definition is 'text', we can't verify – no objections
3. Allow whitespace for attribute values -
because if we change this then 1.0 documents containing white space in attribute
values will fail 1.1 validation
Mark
pointed out, as a related aside, that all suggestions for attribute values so
far in the spec doc need to be made lower case.
These are
still under discussion and need to be agreed yet.
3.4 Extension Points
From Yves' mail.
Where we
have extension points, they are defined as ‘##other’. Another option here is to define them as
‘##any’. The difference is
described here.
Any -
allows xliff elements to be included here
Other -
allows any elements except elements from the current namespace ( xliff in our
case)
'elements
from any namespace where that namespace is not the current
namespace'
The issue
is that if we use ‘any’, then users can conceivably embed xliff constructs at
any extension point within another xliff document. I.e. embed xliff within
xliff.
So, the
discussion centres on whether users can add xliff elements at our extension
points, though that is not what we intended these elements to be used
for.
Allowing
this Any is obviously more flexible for the user.
Christian
would not like users to have to define totally new structures very similar to
already existing xliff structures just because we don’t allow them to embed the
already existing ones (be specifying ‘other’)
Enda
argued that from a tools perspective allowing by specifying ‘any’ and allowing
xliff constructs to be embedded at points in an xliff doc where they were not
intended would result in very messy and difficult to read xliff
documents.
Yves
pointed out that it would be a way for us to refine xliff by seeing where our
spec is limited, Enda, said this is a major issue for the tools. Tools won't know what to do with, say a
<trans-unit>, that is found in a place it was never expected. We have already agreed that tools should
ignore constructs they don’t understand.
This muddies the waters a bit because, in theory, we do understand
<trans-unit>s. However, if we
come across a <trans-unit> as a child of a <trans-unit>, what do we
do?
Tony
suggested that perhaps it would be obvious that these are extensions and not
part of the core document because they will be prefixed by a namespace eg.
urn:xliff.trans-unit. Research and
samples are needed on this, people were not 100% sure (when embedding constructs
from same namespace)
Shigamichi
- would like to do some more research, he would like to see an example of how
people use this 'ANY'.
Christian
& Yves will try to come up with examples and make a recommendation for the
next meeting.
Mark
pointed out that this may not be a global discussion, maybe we would need any
sometimes and other in other times.
Enda
|
Tel
: (353)-1-708 2817 |
|
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC