[xliff] Amended XLIFF Teleconference Minutes - 11 Feb '03

[Enda McDonnell <EndaMcD@alchemysoftware.ie>]

Hi All,

Apologies, but I missed the minutes from the last two items (item 18 and 19) discussed at yesterdays meeting.  John Reid has kindly provided me with these minutes and all are now included here.

 

Best regards,
Enda

 

1 Attendance

Present

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 

 

Apologies

Bryan Schnabel, Tektronix
Peter Reynolds, Bowne Global Solutions, TC Secretary

 

2 Previous Meetings’ Minutes

Mark motioned to accept Minutes from last week, Shigamichi seconded the minutes

 

 

3 Review open items in Tracking Report

 

3.1 Validation of XLIFF 1.0 with 1.1 Schema  (item 14 in tracking report)

 

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

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)

Outcome

 

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.

 

3.5 context-type  (item 18 in tracking report)

Discussion

There was some reference in a previous discussion to context-type having multiple values listed in a single <context> instance; e.g. (my example):|
<context context-type="x-myvalue database linenumber"></context>

Yves wanted to know if that is the case since 1) the schema for allowing multiple enumerated values along with extended values (using a pattern) in a list a an attribute is quite awkward and 2) it is not defined that way currently. The general concensus was that only one context-type value should occur per <context> instance; e.g. (my example):
<context context-type="x-myvalue"></context>
<context context-type="database"></context>
<context context-type="linenumber"></context>

Mark had tried allowing multiple enumerated and extended values in an attribute value and thought it had validated with a simpler schema definition.

Outcome

Decision: context-type is unchanged (only one value per instance).
Action Item: Mark will verify his results and pass it on to Yves.

 

3.6 Consolidated Attribute Values Lists (item 19 in tracking report)

Discussion

- Gérard had proposed consolidating the attribute values for count-type with datatype, restype, and state.

- John was unsure how to implement the proposal in a schema. He was concerned that the count-type values would still need to be enumerated independently of restype, datatype, ands state with this proposal.

- Christian was concerned about having to parse attribute values. There was some discussion about what the count-type refers to.

- John thought that the proposal might be defining way to point at what was being counted within the XLIFF without using xpath but that it was very much xpath.

- John opined that there are 3 options for us: 1) enumerate the count-typs as we have done without reference to datatype, restype, and state; 2) find a method in the schema to refer to the attribute values of datatype, restype, and state in the definiion of the count-type (e.g. datatypeValueList | restypeValueList | stateValueList"); 3) find a method to actually refer to what is counted in the XLIFF via the count-type. He thinks that it is too late to do #3 but would be worthwhile to do #2.

- Christian thought we should look at the count work being done by LISA. Yves pointed out that no workhad been done, yet.

Outcome

- Action Item: John will try to implement #2 option, above.

 

Adjournment

At this point the meeting time was over. John moved that we adjourn and Mark 2nd.

 

---

Alchemy Software Development Ltd. Block 2 Harcourt Business Centre Harcourt Street Dublin 2 Ireland Tel : (353)-1-708 2817 Fax : (353)-1-708 2801 Web :www.AlchemySoftware.ie