OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

xliff message

[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]