[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: [no subject]
A. 'id' attribute: In quite a number of context it would be better if one could use GUIDs (since they are available and used for other types of referencing anyhow) B. ordering according to input file: This is constraints would for example prevent people from using the 'group' element (see next remark) in order to provide a container e.g. for all error messages [Tony]A: The 1.1 spec says: "The required id attribute is used to = identify the <trans-unit> within the file." Although it doesn't rule out using = ID for GUID (and in fact we store GUID's in id in the HTML profile), I = think the ID should be used to map to the sequence in the file. If GUIDs are = used they can live in a context-group. B. If we go with my suggestion in A then it works. Just an opinion, = but I think we should keep it simple and recommend not using groups. 8. Allow or recommend the 'group' element =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D A representation like <group restype=3D"string"> <trans-unit id=3D"3" resname=3D"s3"> <source>My Disk</source></trans-unit>=20 <trans-unit id=3D"4" resname=3D"s4"> <source>no files</source></trans-unit>=20 </group> Looks as natural to me as one where the 'restype' attribute is repeated = on each and every 'trans-unit' element. In addition, it causes less repetition/volume and might facilitate/accelerate certain processing = tasks. [Tony]Ok, now I see why you suggested a group structure previously. I = admit this looks cleaner - and if no-one objects then we can adopt this convension.=20 9. Define a schema for validation and conformance testing =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D The profile from my understanding does not use all XLIFF capabilities. Accordingly, one could consider the creation of a schema (in a general sense, not necessarily an XSD). Content producers and tool implementers could use this schema as an additional guidance. [Tony] A good idea, but I think it goes beyond the scope of our stated objectives. Maybe this could be done later. 10. Specify conformance levels =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D Since some features may be hard to implement (cf. Florians posting http://lists.oasis-open.org/archives/xliff/200509/msg00013.html) one = could imagine a distinction of different levels of conformance. This is an approach which for example is taken for XSL:FO (cf. http://www.w3.org/TR/2001/REC-xsl-20011015/slice8.html#conform). In our case, we could for example specify go for A. basic conformance: Wrt. variable handling, an implementatiion with basic conformance keeps the original format for example =09 template =3D At {2,time,short} on {2,date,long}, we detected the planet. Wrt. to capability X, and implementation with basic conformance ... B. complete conformance:=20 Wrt. variable handling, an implementatiion with complete conformance uses the placeholder mechanism for example At <ph id=3D"1">{2,time,short}</ph> on <ph id=3D"2">{2,date,long}</ph>, we detected the planet. Wrt. to capability X, and implementation with complete conformance ... [Tony] Good suggestion, but having more than one recommended level of support adds a level of confusion that will be counterproductive. The suggestion brings to mind TMX's 3 levels of support, which I would = rather we didn't introduce with these profiles. It may be best to omit tagging of replaceables altogether in this profile as Florian had previously = suggested, and define only the basic case for the purpose of interoperability. We = may introduce more complex profiles in the future that address advanced = editor features. This approach may not be ideal but it will at least be = consistant across the profiles we're working on. Any comments? --------------------------------------------------------------------- To unsubscribe from this mail list, you must leave the OASIS TC that generates this mail. You may a link to this group and all your TCs in = OASIS at: = https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php=20
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]