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] Specification Update


Here is an update of the specification and schema.
Note that the file naming convention and draft numbering now follow OASIS
guidelines. Not very elegant and very long. Tony, Do we need to have 'core'
in our case?


--- Issue #4:
No resolusion at this time. Will be deferred if no proposal.


--- Issue #6:
Solution implemented. Should be closed in the Issue List.


--- Issue #14:
A note about how to validate previous compatible version of XLIFF with the
new schema has been added at the bottom of section 3.1.


--- Issue #15:
The xid attribute has been added. Please revise its definition to make sure
I got it right. Also: currently the type for xid is set to 'string' because
id is also set to 'string'. Did we decided something about the type of id?
(keeping backward compatibility in mind).


--- Issue #16:
The 'strongly' in section D.2 has been removed.


--- Issue #17:
Most '##other' have been replaced by '##any'. There are two cases were it is
not possible (yet). In the <group> and in the <header> element. The MS XSD
Validator gives error if ##any is used there. Christian has looked into it
and it seems the problem comes from the fact that both element have not a
deterministic content as specified in the schema specification (see below):

<Quote>
Wildcards are subject to the same ambiguity constraints (Unique Particle
Attribution (§3.8.6)) as other content model particles: If an instance
element could match either an explicit particle and a wildcard, or one of
two wildcards, within the content model of a type, that model is in error.
Schema Component Constraint: Unique Particle Attribution
A content model must be formed such that during ·validation· of an element
information item sequence, the particle contained directly, indirectly or
·implicitly· therein with which to attempt to ·validate· each item in the
sequence in turn can be uniquely determined without examining the content or
attributes of that item, and without any information about the items in the
remainder of the sequence.
NOTE: This constraint reconstructs for XML Schema the equivalent constraints
of [XML 1.0 (Second Edition)] and SGML. Given the presence of element
substitution groups and wildcards, the concise expression of this constraint
is difficult, see Analysis of the Unique Particle Attribution Constraint
(non-normative) (§H) for further discussion.
NOTE: Because locally-scoped element declarations may or may not have a
{target namespace}, the scope of declarations is not relevant to enforcing
either of the two preceding constraints.
</Quote>

Resolution needed, suggestions welcome.


--- Issue 18:
No change needed. I couldn't find again the example that made me thing
several values could be used in context-type. Hallucinations probably. Issue
need to be discared.


--- Other Issues:
Definition for purpose replaced from Marks research. Easier to maintain than
a full regular expression.
By the way: should I replace the pattern everywhere to NOT allow spaces in
user-defined values?


Notes to Tony:
- Issues #4 and #20 seem to be the same.
- I'll be out of the office all next week.



kenavo,
-yves

Attachment: xliff-core-1.1-draft-09.zip
Description: Zip compressed data



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


Powered by eList eXpress LLC