RE: [xliff] Content of <sub> element

["Doug Domeny" <ddomeny@ektron.com>]

Rodolfo,

This philosophical debate has existed for a long time. There are two
camps regarding interpreting U.S. constitutional law: (1) only those
this stated in the constitution are permitted, and (2) all things are
permitted except those prohibited by law. Common sense lies between the
two.

In regard to tags, the question is: should the schema strictly define
what is valid and all else is invalid, or detect that which is in
conflict and disorderly.

Empty <mrk/>, <source/>, and similar tags may not have positive meaning,
but they are not incoherent. Their meaning is "ignore me". They are
neutral, but not negative. They neither add value, nor take it away.

Although I cannot think of a useful application that contains them,
someone else might. Often I have to stretch the HTML spec to workaround
some problem. Additionally, the XLIFF document may be in an intermediate
state and the empty tags may be some sort of placeholder (yes, an 'id'
would make sense).

Here's my suggestion. We can have the strict schema (where support by
the W3C XML Schema standard) enforce text within tags. This checks not
only validity, but also best practice and meaningful content since an
empty tag is likely an error. The strict schema not only tests for
errors, but warnings.

The transitional schema would allow empty tags.

A tool that consumes XLIFF would need to handle empty tags, probably by
ignoring them. A tool that produces XLIFF should not create empty tags;
however, speaking from experience, preventing empty tags could add a lot
of complexity to the tool, thereby negatively affecting cost and
performance.

In the end, people will also produce sloppy markup and the tools we make
need to be reasonably tolerant.

Doug

-----Original Message-----
From: Rodolfo M. Raya [mailto:rmraya@maxprograms.com] 
Sent: Wednesday, September 17, 2008 1:00 PM
To: xliff@lists.oasis-open.org
Subject: Re: [xliff] Content of <sub> element

On Wed, 17 Sep 2008 11:03:30 -0400
"Doug Domeny" <ddomeny@ektron.com> wrote:

> In general, an element that allows text wouldn't require it. The P tag
> in HTML doesn't require text according to the schema, but the spec
> recommends browsers to ignore empty P tags.


According to all replies an empty <source/> element is valid, but I
doubt it can be useful.

"The <mrk> element delimits a section of text that has special meaning"
is written in the specs, but if we allow it to be empty, what would be
delimited?

An empty <internal-file/> element would also be valid if we consider an
"embedded file" as text, but does it make sense?

An empty <note/> without attributes would also be allowed, but it would
be meaningless.

I understand the desire to have similarities with other standards, but
I think that HTML is not a good choice for making comparisons. For
example, an empty <p/> has a meaning, as it is used as vertical
separator.

So, I think that there may be elements which could be left empty,
provided that they are useful due to their attributes. However, I think
that elements like <source> or <mrk> should always have content.

Best regards,
Rodolfo

---------------------------------------------------------------------
To unsubscribe from this mail list, you must leave the OASIS TC that
generates this mail.  Follow this link to all your TCs in OASIS at:
https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php