| Hi all,
In order to free Andrew up to run the meeting, I took on the role of secretary for today’s meeting. My minutes are included below:
[0] Attendance - Christian Lieske (SAP)
- David Walters (IBM)
- Andrew Swift (SDL)
- Arle Lommel (GALA)
We did not review or approve previous meeting minutes. [1] Run-through of wiki content [1.1] Storage options - Andrew: We were discussing of how to store content of native markup. We have three options: (a) no storage; (b) storing it in the element; (c) pointing to an external reference. We want to make translation units independent so any external reference would have to be within the trans-unit rather than in the document skeleton or elsewhere in the file. Including the native content in the element is nice for editing, but if it is complex, it can get in the way.
- Arle: If TM interoperability is a goal, we need to support at least (a) and (b), since both of these are used.
- Andrew: There is also the issue of editing, where having access to the code is useful.
[1.2] Editing hints - Andrew: Editing hints. Should these be included in the specification. We identified four types: can the code be removed, replicated, moved in order, moved outside of a hierarchy location.
- Arle: There is a risk for this in complex formats.
- Andrew: It can't be decided independently of the file format. So do we have a way to pass this along with the file.
- Arle: I think it makes sense to have a way to indicate this with the caveat that there are risks. We'd need to have a way to specify this on a per-format basis somewhere else.
- Andrew: I'd see this as a bonus feature, not something required for a basic implementation. This is something that is extra that we have to do at this point, so the editing experience could be improved.
- Arle: Would it be a global declaration or on each tag, or both?
- Andrew: I don't know.
- Arle: Some times it would be nice to have a global statement, like saying you can remove <i> tags in HTML when going into Japanese
- Christian: I think an ITS-like mechanism would be good (it allows global and local rules). We also need to address when tags can be modified or added.
- Andrew: That is an interesting issue: where do we allow adding tags. Can we specify file-type-specific metadata about the allowable tags.
- Arle: If you allow adding, it bring in all sorts of logistical problems since different users could do different sorts of things
- David: If we start having specific rules for formats and include format-unique functionality, does it take us too far from the base function of XLIFF?
- Andrew: We want to remain agnostic, but we need to allow for extra things for editing.
- Arle: This is a fundamental tension. If you want to enable editing features, you have to be somewhat specific, and can't be generic.
- Andrew: And if you get something so generic that it can handle all file types, it won't be useful in real life.
[1.3] Display values - Andrew: Do we need display values to hide the ugliness of native codes? Should we have a shortcut that explains what the content is? What about linguistic equivalents (e.g., letting people know that © = ©)?
- Arle: I think these equivalents are needed. For example you could get ő which is useless to a translator, who would need to know that it is actually ő (o double acute). We need to consider the ergonomic requirements of users.
[1.4] IDs - Andrew: Issue of mapping tags using same ID or separate IDs.
- Christian: I've not had time to research the xml:id item.
- Arle: I think we might have to have some sort of ID that is global to allow for pairing across trans-unit boundaries
- David: the example of “<sc id='1'>text<ec id='2' rid='1' />” should be “<sc id='1' />text<ec id='2' rid='1' />”
[1.5] Common attributes - Andrew: Is there value in representing tags at a generic level so you know the purpose of the tags?
- David: It would be useful. But the problem right now is that there is a finite list that gets augmented all the time.
- Arle: We might want to look at a registry-type mechanism (external to the specification) for these things. i.e., if someone encounters something new they can submit them to be added to the list.
- David: That seems like a good way to handle it.
[1.6] “Nasty inline” codes - David: I posted some examples of codes with several hundred characters, whitespace, etc.
- Arle: Javascript in HTML tags is a common example that can get really bad.
- Christian: Those people should be disciplined ;-)
- Andrew: I've seen forty-line comments in HTML in some cases. There is some activity on the list to consult about this.
[2] Other items - Arle: Do we have any timelines for our work?
- Andrew: Not that I know of. We report back in the main committee as we go. We've hit some issues where we depend on decisions in the main committee, e.g., we don't know where segmentation is handled: is it part of the main format or do we have a <mrk type="seg" />-type tag that we need to deal with. We need better coordination. But no on the timelines.
- Andrew: Things are moving along but we need stakes in the ground to work around.
- Christian: Will Arle be regularly participating?
- Arle: Yes.
<end of meeting> |