RE: Discrepancies between the XLIFF 1.2 spec and XSD

[bryan.s.schnabel@tektronix.com]

Hi Mary,

(I'm moving this discussion to the list in preparation for discussing the need for an XLIFF 1.2.x rev to implement fixes - which your ruling renders substantive, and not qualified for errata)

Thank you for letting us know how to proceed.  I understand your answer to the question: "How do we deal with the discrepancy between the 1.2 spec and XSD?" as follows.  In cases where there is ambiguity between spec and schema, errata may be enough.  In cases where there is contradiction between spec and schema, change is substantive and the possibility of preparing an errata is eliminated.  Since the latter condition applies to us, we must reconcile the differences, fix any bugs, and create a new release.

I will add this topic to our August 19 agenda (and invite you to attend if you're inclined). My goal will be for the TC to reach consensus and understanding (alternate opinions are welcome).  I will advocate for Tony's excellent advice that we absolutely, and aggressively limit the scope of a point release to fixing discrepancies and bugs (no scope-creep - do not let our emerging excellent work on XLIFF 2.0 get tangled into the 1.2.1 upgrade). I will also point to Asgeir's excellent work at cataloging the bugs and discrepancies (http://wiki.oasis-open.org/xliff/XLIFF1.2/Errata) as the place where we begin to define the scope of a point release.

Thanks you,

Bryan


-----Original Message-----
From: Mary McRae [mailto:marypmcrae@gmail.com] On Behalf Of Mary McRae
Sent: Monday, August 11, 2008 7:08 PM
To: Schnabel, Bryan S
Cc: christian.lieske@sap.com; asgeirf@redhat.com; tony.jewtushenko@productinnovator.com
Subject: RE: Discrepancies between the XLIFF 1.2 spec and XSD


Hi Bryan,

  Well, since it's impossible to actually use a schema embedded in a
specification document, my preference (and what was *intended* by the TC Process
committee when they required that schema be maintained in a separate text file)
was that the schema file itself would be normative. In either case, if there's a
discrepancy between the spec and the schema file - that is, if the spec
identifies an element in camel case and the schema happens to use all lower case
- it becomes a substantive change, eliminating the possibility of preparing an
errata.

  Which leaves you with creating a new version (1.2.1?) and following the spec
lifecycle from initial public draft.

Mary

> -----Original Message-----
> From: bryan.s.schnabel@tektronix.com
> [mailto:bryan.s.schnabel@tektronix.com]
> Sent: Monday, July 28, 2008 2:55 PM
> To: mary.mcrae@oasis-open.org
> Cc: christian.lieske@sap.com; asgeirf@redhat.com;
> tony.jewtushenko@productinnovator.com
> Subject: Discrepancies between the XLIFF 1.2 spec and XSD
>
> Hello Mary,
>
> We are in the midst of deciding the best course to fix some bugs in XLIFF
> 1.2.  For the TC to decide is whether to continue to use the errata method,
> or to possibly do a quick turn (optimistic phrase) on a 1.2.x version. I
> will add this to our next meeting agenda (possibly ask you to make a
> celebrity appearance at a future meeting, if things get complicated).
>
> Meanwhile, Christian raises a very good question that you might be able to
> shed some light on (putting aside, for the moment, the question about
> errata vs. 1.2.x):
>
> > - How do we deal with the discrepancy between the 1.2 spec and XSD?
> >
> > Options which may exist are (again OASIS may rule
> > out/give preference to some options):
> >
> > a. general statement "spec wins over XSD"
> > b. general statement "XSD wins over spec"
> > c. spec or XSD are "refined" by means of errata document
> > on a case by case basis
> > d. spec or XSD are "updated"
>
> Thanks,
>
> Bryan
>
> -----Original Message-----
> From: Lieske, Christian [mailto:christian.lieske@sap.com]
> Sent: Thursday, July 24, 2008 11:38 PM
> To: Asgeir Frimannsson; Tony Jewtushenko; Schnabel, Bryan S
> Subject: RE: [xliff] RE: [xliff-comment] XLIFF 1.2 errata, questions and
> comments
>
>
> Hi there,
>
> I started of this exchange with a possibly misunderstood paraphrase of
> the question
>
> > - How do we deal with the discrepancy between the 1.2 spec and XSD?
>
> From my understanding, it is now clearer what I intended to clarify.
> Thus,
> I suggest that the aforementioned rendition of the question is taken to
> the TC.
>
> From my understanding the OASIS rules or best practices may provide
> input to the question.
>
> Options which may exist are (again OASIS may rule out/give preference
> to some options):
>
> a. general statement "spec wins over XSD"
> b. general statement "XSD wins over spec"
> c. spec or XSD are "refined" by means of errata document on a case by
> case basis
> d. spec or XSD are "updated"
>
> A completely separate track would be addressing the discrepancies in a
> 1.2x
> version.
>
> Cheers,
> Christian
>
> -----Original Message-----
> From: Asgeir Frimannsson [mailto:asgeirf@redhat.com]
> Sent: Friday, July 25, 2008 1:36 AM
> To: Tony Jewtushenko
> Cc: bryan.s.schnabel@tektronix.com; Lieske, Christian
> Subject: Re: [xliff] RE: [xliff-comment] XLIFF 1.2 errata, questions and
> comments
>
> On Friday 25 July 2008 06:15:28 Tony Jewtushenko wrote:
> > Gentlemen:
> >
> > Regarding "...publish an early 1.2x or 1.3 that focussed on all the
> fixes,
> > while working on 2.0 as the version where we roll out the new
> features."
> >
> > This statement describes for the 1.2x/1.3 strategy exactly our
> strategy for
> > 1.2 (and 1.1, too).  It was intended to be a short, bug fix and
> must-have
> > implementation that would be much more in line with the current 1.1
> > architecture.
> >
> > My advice is to be very conservative with any features assigned to the
> > 1.2x/1.3 track.  We must be ruthless in triaging features slated for
> this
> > release otherwise we'll get stuck in the mud for 2 years as happened
> with
> > 1.2.
> >
> > My recommendation is that we address only bug fixes in 1.2x.  New
> features
> > should be introduced in 2.0.  We must hold to this rule without
> exception.
> >
> > I also recommend that the 1.2x sped and XSD be published at scheduled
> > intervals - e.g., semi annually or annually.  We should name the dates
> in
> > advance and the release should "leave the platform" with whatever
> > "passengers" are on the "train".
>
> Well said.
>
> I would go to the extent of suggesting we don't publish an 1.2.x or 1.3
> but
> rather take a more formal approach towards publishing an errata document
> with
> all known 'bugs', and then perhaps subsequent erratas (including updated
>
> spec/xsd that addresses these) at regular intervals if new errors are
> found.
> This was my main purpose for drafting the errata document on the wiki
> [1]
>
> [1] http://wiki.oasis-open.org/xliff/XLIFF1.2/Errata
>
> (Should we perhaps take this discussion to the list? - This is no longer
> about
> backwards compatibility)
>
> cheers,
> asgeir
>
> >
> > Anyway, these are my 2 cents.
> >
> > Cheers,
> > Tony
> >
> >
> > -----Original Message-----
> > From: bryan.s.schnabel@tektronix.com
> > [mailto:bryan.s.schnabel@tektronix.com]
> >
> > Sent: 23 July 2008 15:56
> > To: christian.lieske@sap.com; asgeirf@redhat.com
> > Cc: tony.jewtushenko@productinnovator.com
> > Subject: RE: [xliff] RE: [xliff-comment] XLIFF 1.2 errata, questions
> and
> > comments
> >
> > Hi Christian,
> >
> > I will keep this reply off list as well.  I agree that keeping 2.0
> backward
> > compatible is a good, and achievable goal. But I really like Asgeir's
> idea
> > that we could publish an early 1.2x or 1.3 that focussed on all the
> fixes,
> > while working on 2.0 as the version where we roll out the new
> features.
> >
> > Thanks,
> >
> > Bryan
> >
> > ________________________________________
> > From: Lieske, Christian [christian.lieske@sap.com]
> > Sent: Wednesday, July 23, 2008 3:31 AM
> > To: Asgeir Frimannsson; Schnabel, Bryan S
> > Cc: Tony Jewtushenko
> > Subject: RE: [xliff] RE: [xliff-comment] XLIFF 1.2 errata, questions
> and
> > comments
> >
> > Hi Bryan and Asgeir,
> >
> > Please lets distinguish:
> >
> > - How do we deal with the discrepancy between the 1.2 spec and XSD?
> > - How do we move beyond 1.2?
> >
> > Personal notes (thus, not to the list):
> >
> > I see a serious danger in giving the impression that a possible 2.0
> > will not be backward compatible.
> >
> > In addition, I am not sure that a features like "bare-bones" XLIFF
> > (at least not the one I tried to sketch) can only be realized by
> > means of incompatible changes. From my understanding, a modularized
> > XSD would have done the job.
> >
> > Cheers,
> > Christian
> > -----Original Message-----
> > From: Asgeir Frimannsson [mailto:asgeirf@redhat.com]
> > Sent: Wednesday, July 23, 2008 2:01 AM
> > To: xliff@lists.oasis-open.org
> > Subject: Re: [xliff] RE: [xliff-comment] XLIFF 1.2 errata, questions
> and
> > comments
> >
> > On Wednesday 23 July 2008 02:58:00 bryan.s.schnabel@tektronix.com
> wrote:
> > > As for your question about the spec trumping the schema when there
> are
> > > differences, I think that is a good rule.  This one of the reasons
> I'd
> > > really like to get an official working draft version of XLIFF 2.0
> >
> > passed
> >
> > > and posted.  Not only would it be a start for the new features we're
> > > developing, it would also give us an "official" place to post fixed
> > > versions of the XSD that Doug has been quick to make.  I will
> propose
> >
> > to
> >
> > > the TC that we make penning and passing a working draft, along with
> >
> > working
> >
> > > draft XSDs a TOP priority.
> >
> > I'm wondering if it better to branch into 1.3 (or 1.2.1) AND 2.0 at
> this
> >
> > point, where the 1.X branch is backwards-compatible to 1.2, and the
> 2.0
> > branch
> > can safely break backwards-compatibility. This is essential to support
> > some of
> > the suggested features such as "a bare-bones XLIFF core, then provide
> > extension modules...". This will also give 1.2 implementers a way of
> > safely
> > updating to a stable 1.2.x rather than directly to a fluffy new 2.0.
> >
> > Just a though.
> >
> > cheers,
> > asgeir
> >
> >
> > ---------------------------------------------------------------------
> > 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