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


Subject: [xliff] issue 3 (new elements "default" and "defaults"): request forclar ification


Dear all,

As promised during the last TC phone conference, I am about to generate
new suggestions related to the proposal. I start from a list of
requirements which the suggestions should address. Here are the requirements
from which I started: 

R.1 a mechanism to allow defaulting for XLIFF data categories
R.2 formal representation of data category is secondary (i.e. the
    mechanism should be applicable to attributes and elements)
R.3 mechanism should work for all XLIFF data categories
R.4 location for defaulting information is secondary (i.e.
    default in central location, default at specific attributes or
    elements, and default at all attributes and elements is
    acceptable)
R.5 XPath should not be used to relate default settings to the
    elements or attributes to which they pertain (let's call this
    'target')

To me, these requirements boil down to three questions:

Q.1 What is defaulted?
Q.2 How is it defaulted?
Q.3 Where is it defaulted?

The proposal (I will refer to this as 'P1') I originally submitted (which did not
meet R.5) answered the questions as follows:

P1.A1 allow defaulting for any XLIFF data category
P1.A2 use XPath to designate the targets for default settings
P1.A3 use a new central element 'defaults'

Unfortunately, I am not able to work in detail on all of the proposals we discussed.
Since I don't see a way to come up with a list of defaultable data categories (I
mentioned this in the meeting), I refrain from any attempt of starting this endeavour.
Hopefully, others will be able to pitch in here.

Nevertheless, here are some thoughts which try to capture what we discussed, open
issues, and an alternative to my original proposal.

P1': like P1 but without XPath

     One possiblity for doing away with XPath would be the following:

     	<defaults>
		<default id="1">
			<dataCat>maxwidth</dataCat>
			<value>72</value>
		</default>
		<default id="2">
			<dataCat>xml:lang</dataCat>
			<value>en</value>
		</default>
	</defaults>
	...
	<trans-unit default="1,2">
		<source>...</source>
	</trans-unit>

	The idea here is that each target explicitly names the defaults which
	should be used for it. From my understanding, this is not really
      kosher, since for example the way to identify relationships (or 'targets')
      is a proprietary and not very efficient one. XPath is the standard for this.
      Accordingly, I would ask the TC members to reconsider my original proposal.

P2: defaults are encoded at the level of the 'group' element (John's proposal)

    todo: a) define defaultable data categories (Q.1)
	    b) design a representation for default settings (Q.2); this has
	       include a way to identify to which XLIFF data category a
             default setting pertains
	
P3: defaults are encoded 'in the vicinity' of the XLIFF element to 
    which they pertain (Mark's proposal)

    todo: a) define defaultable data categories (Q.1)
	    b) define 'in the vicinity of' (Q.3)
          c) design representation (Q.2)

Best,
Christian



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


Powered by eList eXpress LLC