Closed yumaoka closed 2 years ago
Hi,
Valid prefixes must be registered with the XLIFF TC. See https://wiki.oasis-open.org/xliff/FragIDPrefixRegistration
The list of accepted prefixes is currently available at https://tools.oasis-open.org/version-control/browse/wsvn/xliff/trunk/xliff2-fragid/registry.txt
OpenXLIFF validation follows the rules for fragment IDs. Your suggestion makes sense, perhaps it could be another change for future versions of XLIFF.
Regards, Rodolfo
Hi Rodolfo, this is for validating custom value used for subType
and subState
. The FAQ found in the page. My interpretation of the statement below is that you don't need registration of prefix for this case.
Technically no. However, it is strongly encouraged to A) be consistent and use the same prefix for both mechanisms in your custom data and B) to register the prefixes even if they are only for attribute values. In such case it is recommended for the registered URI to be a URL pointing to a public page where the attribute values are described.
If registration of prefix is required for subState
, it implies no one can use it at this moment, because there are no predefined values available for subState
attribute, and no custom prefix is registered for subState
values at this moment.
My interpretation of the spec is that users can define their own value of subState
for their purpose. But the value must be composed by prefix + ':' + sub-value. so for example <segment id="s1" state="initial" subState="foo:bar">
is not violating the spec.
However, for data interchange purpose, it is recommended that such users who want to use subState
attribute register their own prefix and definition of values.
Because a value of these attribute is out of XML namespace's scope, declaring XML namespace in <xliff>
element for a prefix used in subType
and subState
does not really make sense (although it's still not violating XLIFF specification if my understanding is correct).
I think XLFF validator should check if subState
/subType
value contains :
(because it mandates prefix + ':' + sub-value construction), but should not invalidate even prefix is not a known namespace for XLIFF.
Hello Yoshito,
In the first topic of the FAQ you can read this:
What if I don't register a prefix with my extension? If your extension doesn't use IDs it's OK.
If your extension uses IDs, no-one will be able to point to an element of your extension if they don't know the prefix to use, and more importantly: XLIFF 2 validators will flag as invalid any documents using fragment identifiers with un-registered prefixes.
This means that if you don't register a prefix, the fragment identification feature is unusable. This is really silly.
The validator is doing what the XLIFF TC says. What needs to be fixed is the requirement imposed by the XLIFF TC. Once that has changed, the validator will be updated accordingly.
Opened an issue on XLIFF 2.2 repository to implement the change in future versions of XLIFF.
The specification doesn't require subState values to be registered See http://docs.oasis-open.org/xliff/xliff-core/v2.1/os/xliff-core-v2.1-os.html#substate It just gives a permission to register subState prefixes
Invalidating subState attributes with unregistered prefixes is not conformant with the current specification. The specification doesn't need to change in order to fix the validation behavior.
The confusion might come from the fact that the registration mechanism for the subState (or subType) prefixes is the same as for fragid. Registration of fragid prefixes for element based extensions is required, otherwise pointing to data in private elements in impossible..
According to XLIFF 2.0 specification, XLIFF user can define subState/subType values with custom namespaces.
For example, example XLIFF below defines a custom namespace
abc
andabc:mt
is used forsubState
attribute in<segment>
element.My understanding is that this is supported by XLIFF 2.0 specification. However, the validator returns an error -
Invalid prefix 'abc' in "subState" attribute
com.maxprograms.validation.Xliff20 has a list of known prefixes (namespaces) as below.
The list is fixed, so any other prefixes not included in this list will be invalidated. BTW, "my" in this list is not defined by XLIFF specification, but it is used in some examples in the specification. The validator probably should append namespaces declared in
<xliff>
element toknownPrefixes
for validating subState/subType values.