RE: [xliff] RE: How do we refer to an external skeleton in XLIFF 2.0?

Good catch David. Sorry that I hadn’t noticed that before.

I don’t mind your solution.

But it seems a bit odd to me that if I’m interested in information about an external skeleton I need to know to look at the <file> element, but if I’m interested in information about an internal skeleton I need to know to look at the <skeleton> element. This confusion is exacerbated by the fact that in XLIFF 1.2 each case was supported in the <skl> element.

So I guess my (not passionate) vote would be to leave the @href on <skeleton>, and remove the @skeleton from the <file> element.

From: Dr. David Filip [mailto:David.Filip@ul.ie]
Sent: Tuesday, April 09, 2013 2:02 PM
To: Dr. David Filip
Cc: Schnabel, Bryan S; Ryan King; xliff@lists.oasis-open.org
Subject: Re: [xliff] RE: How do we refer to an external skeleton in XLIFF 2.0?

Bryan, this seemed reasonable to me last week.

However, your proposal started with the question how do we refer to an external skeleton in XLIFF 2.0

And looking at the spec today I figured, there was a way to point to external skeleton even before your skeleton attribute was introduced.

So now we unfortunately have two totally analogical mechanisms for pointing to an external skeleton..

- skeleton attribute on file, which exludes usage of the skeleton element

- ahref attribute on skeleton that forces the skeleton attribute to be empty.

I guess this can only create confusion. It would force people to look for the external skeleton at two places and would introduce a superfluous dilemma for implementers.

I actually do not care which of the two mechanisms we keep, I just guess we should keep only one.

I propose to roll back the new attribute on skeleton. I may add a note that external skeleton is being pointed to from file via the skeleton attribute.

I would also make the skeleton attribute value an IRI rather than text.

@Everyone, please let me know if this seems OK, or if you prefer it the other way round, eventually if you have a use case that would support having the mechanism at both levels..

Cheers

I won't

Dr. David Filip

=======================

LRC | CNGL | LT-Web | CSIS

University of Limerick, Ireland

telephone: +353-6120-2781

cellphone: +353-86-0222-158

facsimile: +353-6120-2734

mailto: david.filip@ul.ie

On Tue, Apr 2, 2013 at 1:50 PM, Dr. David Filip <David.Filip@ul.ie> wrote:

Dr. David Filip

=======================

LRC | CNGL | LT-Web | CSIS

University of Limerick, Ireland

telephone: +353-6120-2781

cellphone: +353-86-0222-158

facsimile: +353-6120-2734

mailto: david.filip@ul.ie

On Tue, Mar 26, 2013 at 5:09 PM, Schnabel, Bryan S <bryan.s.schnabel@tektronix.com> wrote:

Hi Ryan,

It just seemed to me that having an embedded skeleton, and a reference to an external skeleton could lead to ambiguity. Seems like we want one or the other, per <file> element.

Thanks,

Bryan
________________________________
From: xliff@lists.oasis-open.org [xliff@lists.oasis-open.org] on behalf of Ryan King [ryanki@microsoft.com]
Sent: Tuesday, March 26, 2013 9:55 AM

To: Schnabel, Bryan S; xliff@lists.oasis-open.org

Subject: [xliff] RE: How do we refer to an external skeleton in XLIFF 2.0?

Hi Bryan, All,

I agree with adding the reference to an external skeleton, just wondering why we want to have a processing instruction specifying that <skeleton> would not be extensible if this reference is present.

Thanks,
Ryan

From: xliff@lists.oasis-open.org [mailto:xliff@lists.oasis-open.org] On Behalf Of Schnabel, Bryan S
Sent: Monday, March 25, 2013 5:16 PM
To: xliff@lists.oasis-open.org
Subject: [xliff] How do we refer to an external skeleton in XLIFF 2.0?

I notice the <skeleton> element has no attributes. This if fine for internal skeletons. But what if we want to refer to an external skeleton? I think we should add an optional @href. And I think the processing requirement is that the skeleton can have either the @href, or “XML elements from any namespace” – but not both.

I also think that the intention all along was that we could have an external skeleton. So I think this is not a substantive change that needs a ballot.

If anyone thinks it is substantive, please reply with your thoughts to this thread. If nobody chimes in, I think David and Tom should go ahead and make the changes w/o ballot.

Thanks,

Bryan

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