Outcome
Doug 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> ?  
(item 15 in tracking report)
 
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 (item 
16 in tracking report)
 
Summary
 
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.
 
 
Discussion
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.
 
Outcome
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
 
 
Aside
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 (item 17 in tracking 
report)
 
Summary
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.
 
Discussion
 
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)