[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [xliff] RE: How do we refer to an external skeleton in XLIFF 2.0?
+1On Tue, Mar 26, 2013 at 5:09 PM, Schnabel, Bryan S <firstname.lastname@example.org> wrote:
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.
From: email@example.com [firstname.lastname@example.org] on behalf of Ryan King [email@example.com]
Sent: Tuesday, March 26, 2013 9:55 AM
To: Schnabel, Bryan S; firstname.lastname@example.orgSubject: [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.
From: email@example.com [mailto:firstname.lastname@example.org] On Behalf Of Schnabel, Bryan S
Sent: Monday, March 25, 2013 5:16 PM
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.
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: