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 =
the <trans-unit> within the file."  Although it doesn't rule out using =
for GUID (and in fact we store GUID's in id in the HTML profile), I =
the ID should be used to map to the sequence in the file. If GUIDs are =
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

A representation like

	<group restype=3D"string">
		<trans-unit id=3D"3"  resname=3D"s3"> <source>My
		<trans-unit id=3D"4" resname=3D"s4"> <source>no

Looks as natural to me as one where the 'restype' attribute is repeated =
each and every 'trans-unit' element. In addition, it causes less
repetition/volume and might facilitate/accelerate certain processing =
[Tony]Ok, now I see why you suggested a group structure previously. I =
this looks cleaner - and if no-one objects then we can adopt this

9. Define a schema for validation and conformance testing

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

Since some features may be hard to implement (cf. Florians posting
http://lists.oasis-open.org/archives/xliff/200509/msg00013.html) one =
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
		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
		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 =
and define only the basic case for the purpose of interoperability. We =
introduce more complex profiles in the future that address advanced =
features.  This approach may not be ideal but it will at least be =
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 =
at: =

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]