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
>