This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
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.
(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