W3C home > Mailing lists > Public > public-i18n-its@w3.org > April to June 2006

Re: Versioning

From: Felix Sasaki <fsasaki@w3.org>
Date: Thu, 06 Apr 2006 23:15:25 +0900
Message-ID: <4435227D.3070209@w3.org>
To: "Lieske, Christian" <christian.lieske@sap.com>
Cc: Yves Savourel <ysavourel@translate.com>, public-i18n-its@w3.org
Lieske, Christian wrote:
> Hello everyone,
> As mentioned in
> http://lists.w3.org/Archives/Public/public-i18n-its/2006AprJun/0024.html
> I think that the "multiple rules" assumption should be discussed.


> I still see a need for a version attribute on the rules element
> (beneficial for example for linked rules files since those files
> otherwise would not have an indicator to which version they belong).

we decided to link via a xlink attribute which points to a file. If the
top element of that file has a version attribute, you will take the
version. If not, the version is the one indicated at the top element of
the including file.

Where is the problem / tricky case with this solution?

> The suggestions related to working with different rules are sensible.
> I would propose not to discuss this during the call on Friday since
> it is from my point of view a general technical discussion (and the
> call on Friday is related to editing).

+1 for this, but we need to spend enough time to discuss this via mail.
The decision on this topic is overdue.

So please participate ASAP - everybody ;)

- Felix

> Best,
> Christian
> -----Original Message-----
> From: public-i18n-its-request@w3.org
> [mailto:public-i18n-its-request@w3.org] On Behalf Of Felix Sasaki
> Sent: Donnerstag, 6. April 2006 04:10
> To: Yves Savourel
> Cc: public-i18n-its@w3.org
> Subject: Re: Versioning
> Hi Yves, all (making the cc list smaller),
> +1 to follow your proposal for "1.0" version only at the root element,
> and a proposal for the question "different versions processed together":
> - position of version attribute: root of the document (as you proposed).
> - interpretation of a version attribute: we say that a version attribute
> always decides the version of markup from the ITS namespace at the
> element the attribute is at, or child elements, including attributes.
> - question of how different versions are processed together:
> if the version attribute is missing, the version "1.0" is assumed. If
> the version attribute is present and there is a value different than
> "1.0" in the version attribute, "forwards-compatible" mode is evoked.
> That means: an ITS 1.0 can skip markup from the ITS namespace which is
> not defined in ITS 1.0.
> In other words, an ITS 1.0 processor running in "forwards-compatible"
> mode needs to process only the following elements / attributes:
>  rules
>  ns
>  prefix
>  uri
>  selector
>  span
>  translateRule
>  translate
>  locInfoRule
>  locInfo
>  locInfoPointer
>  locInfoType
>  locInfoRef
>  locInfoRefPointer
>  termRule
>  termRef
>  termRefPointer
>  term
>  dirRule
>  dir
>  rubyRule
>  rubyPointer
>  rbPointer
>  rtPointer
>  rpPointer
>  rbcPointer
>  rtcPointer
>  rubyText
>  ruby
>  rb
>  rt
>  rbspan
>  rbc
>  rtc
>  rp
>  langRule
>  langPointer
>  withinTextRule
>  withinText
> if there would be other elements / attributes from the ITS namespace,
> and the version would be "1.0" (i.e. not "forwards-compatible" mode),
> that would be an error, which MUST be reported to the user.
> Rational for this proposal, which is (only partially) based on
> http://www.w3.org/TR/xslt#forwards :
> a new version means *not* a new interpretation for same markup, e.g.
> <its:rules>, <its:selector> etc., but for new markup, e.g.
> <its:new-exciting-1.1-feature>. Hence, the purpose of a version
> attribute is to decide: when has a ITS 1.0 processing application to
> understand markup from the ITS namespace, when is it an error if it
> doesn't?
> My impression is that this topic still needs discussion, and I'd propose
> to continue this via mail and on the Friday's call, and to vote about it
> next Tuesday.
> Cheers,
> Felix
> Yves Savourel wrote:
>> Hi Christian, Felix, Diane,
>> A follow up on the version topic. We didn't thought about some cases
>> that makes our current consensus a bit arguable: what if there are
>> several <rules> elements in the document? (it's not forbidden, and may
>> be caused by tools automatically inserting <rules>).
>> Currently we have:
>> #1: If there is only ITS local markup in the document, the its:version
>> goes in the root element of the document.
>> #2: If there is a <rules> element (with or without additional local
>> markup), the its:version goes in the <rules> element, not in the root
> of
>> the document.
>> Issues:
>> --> If 'somehow' a document has an its:version both in the root of the
>> document and in the <rules> element, I assume the one in the root
>> element should be ignored (but things would change if later we decide
> to
>> allow multiple verisons)
>> --> If you have two or more <rules> elements, the its:version in the
>> first <rules> should prevail? Or each version prevails for its
> <rules>?
>> And which one applies the the local markup?
>> I realize that these cases are related to the "do we allows ITS of
>> different versions to be processed together" discussion that we said
> was
>> premature, but it seems very difficult to apply our current consensus
> to
>> those two issues without knowing the answer to the question.
>> I'm a bit concern that all this seems quite confusing compare to just
>> have one its:version in the root element in all cases... (which also
>> makes the "do we allows ITS of different versions to be processed
>> together" question much easier to resolve by restricting the
>> possibilities of different versions to one per document at most).
>> Any comment?
>> -yves

Received on Thursday, 6 April 2006 14:15:35 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:43:07 UTC