Re: [xliff] Design objectives

["Eric D. Friedman" <eric@conveysoftware.com>]

Recommend publishing the final version of these (and other) objectives
in some official part of the TC work area, since design artifacts are
helpful guideposts for future participants and revisions.

> Design objectives
> XLIFF 1.1
> Interoperability
> 1.	It must be possible for applications to process an XLIFF document
> without knowing which vendor produced it.
> 	Mtg: Yes But what is meant by process.

Process == parse and interpret element and attribute content and content
models in the XLIFF namespace.  Content and content models in other
namespaces must not change the semantics of the XLIFF content such
that a tool which does not support those other namespaces would be
perceived to be in error.

So, this would not be OK:

<!-- content model for xliff:foo says that xliff:value is decimal -->
<xliff:foo xliff:value="123"
           evil:othernamespace="value is in octal, not decimal" />


> 3.	Applications must be able to process XLIFF content using all of the
> standard APIs.á
> 	Mtg:Yes but does not have to be SAX

Sure, as long as SAX is supported.  If SAX works, any of the higher level
APIs will work, but the converse is not always the case without huge
effort on the programmer's part.

> 5.	The specification for XLIFF must be based on the W3C XML Schema 1.0
> Recommendation.
> 	Mtg: The proposal from this meeting is to use the DTD and W3C XML
> Schema.

DTD does not work with schema+namespaces+validation.  How do you
propose to address this issue?

> 6.	Applications must not be forced to use the schema to process an
> otherwise valid XLIFF document.á Hence, extensions that redefine elements in
> the XLIFF namespace are forbidden.
> 	Mtg:What about default values

Of course default values are allowed/encouraged.  The point here is that
the mechanisms in schema that allow schema extensions to clobber information
in the base schema should be disallowed, since those mechanisms require
applications to dynamically interpret the result of merging the base schema
and the extensions.  This makes implementation much more difficult than
it needs to be.

> 8.	In the interest of simplifying processing requirements, ordered
> sequences of elements are preferable to content models that do not specify
> an ordering.á In other words, <sequence> is preferable to <choice>.
> 	Mtg: Yes but both <sequence> and <choice> are needed.

Of course.  The point is that given a choice, don't choose choice. :-)

> 13.	Applications must not be required to process xsi:type attributes in
> order to determine if an element is in a supported namespace.á This
> restriction prohibits the use of abstract types (though not abstract
> elements) in XML Schema and is intended to simplify the requirements for
> processing instance documents.
> 	Mtg: For discussion later

OK

> 14.	XLIFF must not contain ôlittle languagesö that are not directly
> supported by XML or XML Schema.
> 	Mtg: No we can try to limit them.

Which little languages cannot be eliminated?

> 15.	Elements bearing user visible comments or instructions must support
> content from the XHTML namespace as well data of other types.
> 	Mtg:Other namespaces such as DocBook might also be appropriate

Sure, but we should limit scope if possible, and consider pushing less
common datatypes into extensions.

> 16.	XLIFF must not specify the use of processing instructions.
> 	Mtg: For discussion with regard to tool neutrality

This isn't an issue of tool neutrality at all, since we aren't
proposing to outlaw PIs in instance documents.  We're simply saying
that the spec must not define PIs as the standard way of accomplishing
task X, Y, or Z, since the futures of PIs in XML is at risk.

> 18.	The state of an XLIFF document within the localization process is
> not part of the document itself. Therefore it must not be represented as
> such in the XLIFF schema.
> 	Mtg:For discussion but probabley no.

OK, however, we should look at each element in this group individually,
since some seem to be more problematic than others.

> Naming and namespaces
> 19.	XLIFF names must be self-explanatory and unambiguous.
> 	Mtg:Yes Whenever possible. See also Migration strategy notes.

When is it not possible to have unambiguous, self-explanatory names?
The migration strategy says that we might use a new namespace for each
version.  In the new namespace, where there are no conflicts, why would
we not make names as clear as possible.

> 20.	All XLIFF elements must be assigned to the XLIFF target namespace.
> 	Mtg: Except that if you extend the XLIFF namespace then it is not in
> the target namespace.

Extensions are not XLIFF elements, so there's no exception case here,
as far as I can tell.

> 21.	XLIFF names must not assume or imply that content or reference
> elements are derived solely from files.
> 	Mtg: Needs further discussion

what are the salient points?

> 	25.	Extensions to XLIFF must not use the XLIFF target namespace.
> If there is a way to do this without touching the target namespace.

Not clear what you mean here, please explain.

> 27.	Extensions must not prevent applications that only understand the
> core XLIFF schema from processing the elements in that schema.
> 	Mtg:Depends on the meaning of process. The formal extensibility is
> what makes it possible for applications to process any extension.

See above.

> 28.	Applications must not modify the contents of elements or attributes
> from extension namespaces they do not support; however, applications may
> modify (and even delete) unrecognized elements or attributes while
> processing a parent element from a supported namespace.
> 	Mtg: No we don't agree but we are not sure if we understand what you
> mean by this.

Here's an example of a an element with content from another namespace.
Assume that the processing application only understands the foo namespace,
not the bar namespace.


<foo:stuff>
  <foo:thing x="1">
    <bar:none />
  </foo:thing>
  <foo:thing x="2">
    <bar:none />
  </foo:thing>
</foo:stuff>

Assume that the processing application's job is to remove "thing" elements
from "stuff" collections where the thing's "x" attribute is > 1.  The
application could safely comply with 28 and remove the second "thing"
element *including* the "none" element contained within it, even though
it doesn't understand the bar namespace.

It's possible that the confusion here is over the word "modify"  -- perhaps
a more precise word would be "move," which is to say that an application
can move an element and all of its children (some of which it may not
recognize) to another node in the document.

There's a distinction to be made here between elements and attributes:
you can't move attributes that you don't understand to another element,
but you can move the element that contains those attributes, and you can
delete that element as well.

> 29.	Typed extension points are strongly preferred over any/anyAttribute
> catchalls.
> 	Mtg:Please expand on what is meant here

We recommend using substitutionGroups because they establish a more
meaningful contract than "any" is capable of providing.

> Implementations
> 32.	Applications must be able to identify all reference elements for an
> XLIFF document by reading that document only.
> 	Mtg:We need clarification on what this means.In particularly
> regarding uri.

This emerged out of our manifest work.  We wanted to ensure that, even
in the presence of manifest, an XLIFF tool didn't need to understand
the manifest in order to locate the reference elements.  So, if a document
gets separated from its manifest, it "knows" which reference materials
belong with it.

Regards,
Eric & Colin