[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Draft Meeting Minutes from FEISGILTT 2015 Infosessions
FEISGILTT 2015 Public Info sessions
Draft meeting minutes Wed June 3, 2015
[participation in particular sessions was not tracked, this list is based on FEISGILTT 2015 participation]
David Filip (ADAPT Centre), Ryan King (Microsoft), Kevin O’Donnell (Microsoft), Felix Sasaki (Individual), Yves Savourel (ENLASO), Bryan Schnabel (Individual), Joachim Schurig (Lionbridge), Uwe Stahlschmidt (Microsoft)
Evren Ay (MotaWord), Jan Bareš (Moravia), David Čaněk (Memsource), Daniel Chin (Spartan Software), Loïc Dufresne de Virel (Intel), Fabio Fantino (Symantec), Roger Fienhold Sheen (infotexture), Andrew Gibbons (Welocalize), David Lewis (ADAPT Centre), Christian Lieske (SAP), Arle Lommel (DFKI), Patrik Mazánek (SDL), Marc Mittag (MittagQI), Phil Ritchie (Vistatec), Chase Tingley (Spartan Software), Andzej Zydroń (XTM International)
Panelists and Ryan confirmed that the XLIFF 2.0 spec is clearly written and provides much more and more useful implementation guidance than the 1.x specs. Confusion about an erroneous inline example clarified with Andrzej. Chase glossed on difference between the general 1.2 and 2.0 approach in OKAPI framework.
Bryan informed the audience about the delay of the XLIFF 2.1 progress. Progress achieved during the f2f before FEISGILTT has been reported by dF and Felix. New expected date for publishing XLIFF 2.1 is by the end of October 2015.
TC currently does not have consensus whether the XLIFF 2.0 spec should be interpreted as forbidding modules at extension points where the modules are not explicitly listed in the prose specification.
Tentative consenus has been reached that 2.1 should have 2 provisions that would disambiguate the situation.
1) Explicit Constraint disallowing module namespaces on extension points where those are not explicitly allowed.
2) Allowing mda module on all extension points. Meaning adding mda explicitly on module extension points where mda hasn’t been explicitly allowed in XLIFF 2.0. Core is not affected by this change. Issue will be further discussed by TC in refular teleconferences.
Also the ctr module should be amended within 2.1 to allow for tracking inline code changes.
Apart from the approved new features (ITS mapping and Adanced Validation), the above amendments will be included plus a number of editorial fixes and clarifications, e.g. erroneous examples of inline codes will be fixed in 2.1 (no errata for 2.0 is planned).
Glossary Module <-> TBX Bais mapping will be published as a Committee Note. The mapping has been so far published in Localisation Focus.
Chase Tingley reported on XLIFF:doc features coverage by XLIFF 2.
The conclusion was that all relevant XLIFF:doc needs represtented by XLIFF:doc features were covered by XLIFF 2.0 spec. Except the tracking of matches usage and preserving match origin when used in core target. This should be largely covered by XLIFF 2.1 between ctr and ITS Provenance mapping. If the functionality is not fully covered by 2.1, the option is to submit an official 2.2 feature request through comment list roughly by October 2015.
Chase and other IN! representatives in the audience (Andrzej) endorsed XLIFF 2 as TIPP payload instead of XLIFF:doc, though both XLIFF:doc and XLIFF payload types should be legal for a transition period.
The rationale for having ULI represented in XLIFF 2.2 requirements gathering was that possibly there could be synergies or dependencies between work/concepts/resources between ULI and the XLIFF Technical Committee amongst others in the area of “segmentation”. Christian captured his reflections of the discussion as follows:
1. XLIFF 2.0 addresses amongst others a number of processes related to segmentation
2. It would be valuable if XLIFF 2.x could capture information on segmentation-related processes such as
a. This file has been segmented with the following ICU segmentation configuration/resources..
b. This file has to be segmented with the following ICU segmentation configuration/resources..
Christian provided some basic information on ICU and ULI to facilitate the discussion. This was welcomed and the participants asked for the following:
1. Christian or David to distribute most relevant ICU and ULI TC information to XLIFF community; candidates:
a. For ULI: conference presentations from Steven or Uwe, or http://www.meta-net.eu/events/meta-forum-2013/posters/uli-presentation.pdf
b. For ULI: Online segmentation tool: http://demo.icu-project.org/icu-bin/icusegments#3/en
c. For ICU: http://site.icu-project.org/
2. A Webinar of ULI for the XLIFF community
Although U extension is valid in BCP 47 syntax that is prescribed for source and target language tags within XLIFF and users cannot be prevented from using the U extension to indicate segmentation, it does not seem possible to standardize usage and semantics of the U extension in XLIFF facilitated exchange. BTW, Mark Davis (at a W3C MultilingualWeb workshop couple of years ago) advised against usage of BCP 47 extensions in structured mark up environments such as XLIFF. This said markup mappings and processing expectations can be specified when extracting from a source environment when the existing segmentation is Some specific reasons against trying to convey segmentation information via extension U within XLIFF 2 core:
1) The source and target language can only be set at root level <xliff>. There are use cases for setting different segmentation rules for different files, groups, or even units, e.g. postal address fields.
2) It would not be clear whether the segmentation rule indicated by the U extension has been applied, is to be applied.
3) Clash of canResegment flag with the instruction/information on segmentation set at the root level via the U extension.
4) Target segmentation in an XLIFF file is driven by the source segmentation, and re-segmenting target target is not possible without resegmenting source and or reordering target segments within a unit.
5) Although mappings and processing expectations for extraction can be specified, XLIFF principally does not normatively prescribe extraction behavior, plus segmentation is expected to be changed during an XLIFF facilitated roundtrip AND is generally NOT expected to be performed at extraction.
The reporter and the audience concluded that a small specialized module would be required in XLIFF 2.2 that would be able to carry the segmentation information/instruction.
The vehicle could be the U extension but in a clear context (has been used/must not be changed/has not been used/has to be used in the next segmentation step etc.). Another candidate vehicle for carrying the instruction/information (and actually the one preferred by the OASIS and ETSI communities) would be embedding or referencing of SRX rules. This would require some ULI break <-> SRX mapping work on the ULI side before submitting to XLIFF TC as a feature request.
If ULI stakeholders decide to sponsor work on such a module, this feature request needs to be formally recorded via the XLIFF comment list (if requestor is XLIFF TC non-member) or on the XLIFF TC working list if requestor is an XLIFF TC member. XLIFF TC will transfer such a requirement into its public working wiki.
Andrzej Zydroń (XTM International) offered to contribute SRX rules for 16 languages to ULI. Needs to be checked for compliance with contribution rules.
Joachim introuduced this as a possible 2.2 feature. Joachim belives that it is an opportunity and inaction threatens the standard by someone else standardizing rendering of layout during the roundtrip. The underlying idea is that of fs, BUT in this case the handling would be strictly standardized and unlike fs this proposed feature would guarantee roundtrip of the layout information including relevant transforms.
dF opined that layout roundtrip is currently possible using resource data module. Resource data module and skeleton are both expected to guarantee roundtrip. Resource data of the mime type html with reference set to “no” would do exactly what Joachim is suggesting. The TC should look into this in more detail if the feature is officially proposed to the mailing list by October and has a TC sponsor to elaborate on it.
Object model approaches by ENLASO, Microsof and SDL (BCM) were briefly introduced and discussed.
Panelists and delegates agreed that XLIFF prose specification actually hints to a serialization independent object model. In some sense the XML serialization of the objects defined in the spec (Ryan) is arbitrary and there is no material reason not to have XLIFF serializations other than XML and not to have a general object model underlying not just the XML serialization, but for instance a JSON serialization etc. The possible standardization targets are 1) other serializations, 2) the underlying object model as prose or maybe an abstract syntax such as the browser DOM as basis of an XLIFF DOM for not only browser implementations 3) maybe also a standard API for retrieving XLIFF fragments in a number of possible serializations, prominently XML, JSON, or RDF.
dF explained that the OASIS XLIFF TC under its current Charter cannot work on a generalized serialization independent object model or other than XML serializations.
The options at hand appear to be:
Not losing focus, preserving critical mass, major stakeholders already on the committee
Legally risky, all XLIFF TC participants since inception would need to recommit their IPR to the re-chartered TC. This could incapacitate the TC for an indefinite period and endanger progress of 2.1 and 2.2 versions.
All current TC members can join w/o admin hassle. The sister committee would have a large membership overlap and work could be easily coordinated, see DITA and DITA Adoption committees. Red tape on setting up the sister committee does not directly affect progress and continuity of work on XLIFF 2.1 and 2.2. Overall less risk and cleaner cut than option 1). Has PR potential for announcements etc.
Requires relatively heavy weight red tape to convene the brand new TC. Active participation requires OASIS membership, so harder to engage e.g. the web community, standardization savvy folks who are W3C members but not OASIS members.
Low admin burden, easily accessible to all interested stakeholders at no cost.
Insufficient IPR protection, participating in the group does not oblige to grant essential patents on RF terms. The final Recommendation work requires chartering of a follow up Working Group that requires W3C membership
Joachim Schurig, Chair of ETSI ISG LIS offered ETSI ISG LIS as a publication channel. The object model and other serializations however need to be first developed and only then could be co-published under the ETSI OASIS MOU.
No one was in favor of option 1), options 2) and 3) received both support. With option 2) having little more traction and perceived as better feasible in terms of development and the publishing of the final standard.
Attachment:
FEISGILTT 2015 Public Info sessions.docx
Description: application/vnd.openxmlformats-officedocument.wordprocessingml.document
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]