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

[Bug 2621] On conformance levels: Have a simple conformance: in situ, with default selectors

From: <bugzilla@wiggum.w3.org>
Date: Fri, 13 Jan 2006 12:26:11 +0000
To: public-i18n-its@w3.org
Message-Id: <E1ExO0R-00046X-Q7@wiggum.w3.org>


------- Additional Comments From fsasaki@w3.org  2006-01-13 12:26 -------
(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 ;)
Received on Friday, 13 January 2006 12:26:17 UTC

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