RE: [xliff] RE: Proposed solution for csprd02 (RE: csprd02 comment

David,

I have no objection to your proposal. But I don’t understand the advantage of explicitly including the XML namespace attributes as core vs. adding them via extensibility.

I will hold off from sending my CFD for 127 and 150 in favor of addressing them at the TC meeting tomorrow. Hopefully we will be able to put these, along with Fragment Identification, to a roll call ballot solution.

Thanks,

Bryan

From: xliff@lists.oasis-open.org [mailto:xliff@lists.oasis-open.org] On Behalf Of David Filip
Sent: Monday, January 06, 2014 1:12 PM
To: Yves Savourel
Cc: xliff@lists.oasis-open.org
Subject: RE: [xliff] RE: Proposed solution for csprd02 (RE: csprd02 comment - xml:lang and xml:space)

Yves, Bryan,

I agree that the default for xml:space is the value inherited from the parent. This is how the behavior is defined in the xml spec.
However I believe that we have a more profound issue with the attributes from the xml namespace, i.e. that they have core status at the explicitly specified locations. But they can also be set at extension points.
Now, for the inheritance it does not matter if the value was set at an extension point or core location and this can lead to unexpected behabior IMHO, as the value can be flipped inadvertently by adding or removing extensions.
I was contemplating several ugly solutions for this issue before the Xmas break, including forbidding setting those attributes where they are not explicitly allowed.

Now, I believe that we should explicitly include the xml namespace attributes as core at all elements that are extensible by other namespaces to avoid the mixed core/extension behavior of the attributes.

The other way out would be to have xlf:space and xlf:lang and these would be automatically disallowed at the extension points by virtue of the ‘other‘ wildcard.

Nevertheless, I believe that the former is cleaner and the right thing to do

Cheers
dF

dF is AFK, so that this had to be typed on his tough phone..
Call me at +353860222158 if this answer does not seem sufficient ;)

On Jan 6, 2014 6:34 PM, "Yves Savourel" <ysavourel@enlaso.com> wrote:

Hi Bryan,

> When you say "For data," do you intend this to be a
> generic term that covers things like codes and original data...

Sorry, no. I meant only the <data> element.

That is the only element with the 'preserve' behavior requirement in the White spaces section.

> And for "4.7.5 White Spaces" no change required?

I don't think so. Nobody commented on that section., so I assume it is fine as it is.

Thanks,
-yves

---------------------------------------------------------------------
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

xliff message