(In reply to comment #0)
> Comment from Francois Richard, only entered into bugzilla by Felix:
> 
> A proposal: Have a simple conformance level: Only in situ attributes, with a
> default scope / selector, and without selector attributes.

I think this is a good proposal, and it is one solution to what Christian
proposed at http://www.w3.org/Bugs/Public/show_bug.cgi?id=2620#c1 , and what I
rejected at http://www.w3.org/Bugs/Public/show_bug.cgi?id=2620#c2 .

I had a look at the conformance of xhtml 2, see
http://www.w3.org/TR/2005/WD-xhtml2-20050527/conformance.html#s_conform
There are only two levels: conformance to the markup definitins ("document
conformance"), and conformance to "xhtml family user agents". It then is defined
in detail how a user agent must behave. I am wondering if that would be useful
for us: Having just two conformance levels (1: markup conformance, 2: ITS
processing conformance), and defining for (2) in detail what it means - without
any optional features.
I think different from conformance is the question what kind of ITS information
occurs in a document, and for that purpose we could use an attribute like the
one Yves proposed in
http://lists.w3.org/Archives/Public/public-i18n-its/2006JanMar/0016.html 
I would propose to use such an attribute *independently* of the conformance
discussion, and have only the two conformance levels mentioned.

I agree with Felix that conformance can be defined independently
from an attribute like the "markupType" sketched in Yves' mail.

Furthermore, I like Felix' suggestion to destinguish between markup conformance 
and processing conformance.

Wrt. to the granularity of the conformance model, however, I am currently in 
favour of a fine grained model (rather than the coarse grained/monolithic one 
proposed by Felix). Such a model (which might be inspired by for example 
http://www.w3.org/TR/2001/REC-xsl-20011015/slice8.html#conform) from my point 
of view would allow an evolutionary path to implementations. Rationale: If it 
turns out that efforts for the implementation of processing conformance which 
takes into account e.g. proper selector handling (ie. all flavours of mixing in-
situ with dislocated selectors) are high, we may not see many implementations 
quickly. If, by contrast, however, we define a basic conformance level in such 
a way that implementation is easy (since e.g. only in-situ selectors need to be
supported) we may see implementations more quickly. From my understanding, 
already basic implementations (e.g. ones just supporting "its:translate") would 
be help us to reach our goal of enhancing internationalization and localization.

(In reply to comment #3)
> I agree with Felix that conformance can be defined independently
> from an attribute like the "markupType" sketched in Yves' mail.
> 
> Furthermore, I like Felix' suggestion to destinguish between markup conformance 
> and processing conformance.
> 
> Wrt. to the granularity of the conformance model, however, I am currently in 
> favour of a fine grained model (rather than the coarse grained/monolithic one 
> proposed by Felix). Such a model (which might be inspired by for example 
> http://www.w3.org/TR/2001/REC-xsl-20011015/slice8.html#conform) from my point 
> of view would allow an evolutionary path to implementations. Rationale: If it 
> turns out that efforts for the implementation of processing conformance which 
> takes into account e.g. proper selector handling (ie. all flavours of mixing in-
> situ with dislocated selectors) are high, we may not see many implementations 
> quickly. 

I see your concerns, but I think we can encourage implementations  by telling
people "this is what ITS is, please implement it". The more complicated the
"this" in the statement is, e.g. concerning conformance levels, the less
implementations we will have. I'm talking about the phase of the ITS tagset
*before* canidate recommendation. If during the canidate recommendation phase a
feature is not implemented, it will just drop out ;)

> If, by contrast, however, we define a basic conformance level in such 
> a way that implementation is easy (since e.g. only in-situ selectors need to be
> supported) we may see implementations more quickly. From my understanding, 
> already basic implementations (e.g. ones just supporting "its:translate") would 
> be help us to reach our goal of enhancing internationalization and localization.
> 
One important difference between xsl and ITS is that xsl defines the behavior of
an applcation, the xsl processor. In the same way, XHTML 2.0 defines the
behavior of the application "user agent". What we need is a name for "this and
this should happen with respect to in situ or dislocated selectors", e.g. "ITS
processor", and then say what the processor should be capeable of. So we would
have conformance a) (to the ITS markup declaration) and b) to the ITS processor.
The important difference between ITS on one hand and xsl / xhtml / svg / .. on
the other hand is that ITS can be used without the "processor" capabilities,
that is just a). ISo we *must* make a) explicit. If we have one or two slices of
conformance for the variant b), does not matter to me.
I'm only worried about this because b) goes far away about a normal tag set.
Well, but that is a fact, no matter if we call the "processor" by name or not. I
see the charter in the background again ;)

input to conformance discussion:
http://www.w3.org/TR/2003/REC-xml-events-20031014/Overview.html#s_event_module_conformance
I like this definition because the properties of XML Events are very similar to
ITS: they are not stand-alone document types, they are supposed to be
integreated into host languages like HTML or DITA. I think we could write a
conformance section like in the link above, with
- document conformance
- host language conformance
- instead of user agend conformance a "ITS processor" conformance. That is the
product we still have to define.

(In reply to comment #0)
> Comment from Francois Richard, only entered into bugzilla by Felix:
> 
> A proposal: Have a simple conformance level: Only in situ attributes, with a
> default scope / selector, and without selector attributes.

The group decided to have this simple level of conformance and regards this
issues as closed. See
http://lists.w3.org/Archives/Public/public-i18n-its/2006JanMar/0098.html