Re: Profiles in SVG 1.2

On Wednesday, March 3, 2004, 11:20:08 AM, Jim wrote:

JL> "Chris Lilley" <> wrote in message
>> Jim, try to stay within the bounds of reality.
>> >> The exit criteria for the Candidate Recommendation phase is at
>> >> least two interoperable implementations over every feature. This
>> >> phase will close at 2359Z on 23 June 2002.

JL> That's true for SVG1.1 specifically - but W3 process only requires 1, so you
JL> could change the goalposts for 1.2.

Conceptually, yes.  Practically, no.

I agree that the Process does allow only one implementation

but its a hard job to get away with that nowadays. The effective rule
is two.

JL> I'm glad that the SVG WG take this further and require the 2 that
JL> is SHOULD'd. "Shown that each feature of the technical report has
JL> been implemented. Preferably, the Working Group SHOULD be able to
JL> demonstrate two interoperable implementations of each feature."

JL> That the implementation requirements for W3 reqs have been known
JL> to be stretched, I didn't think was news to anyone.

OK, especially if you go further back in history; in the current
discussion, though, and for the 'freinds of SVG' specs, no.

To take another example (SVG Mobile 1.1 CR)

>>The exit criteria for this phase is at least two implementations of
>>every feature, one of which operates on the intended target platform
>>for that profile. Additionally, should there be multiple
>>implementations of all of the features on the intended target
>>platform yet no single implementation that covers all of a profile
>>of this specification in one viewer, then the Working Group must be
>>satisfied that this is a reasonably achievable goal.

>>W3C SVG Working Group expects to meet implementations that meet all
>>requirements of this document within the two month Candidate
>>Recommendation period (closing at 1159Z on 23 June 2002). Specific
>>areas where we would appreciate further experience are:

>>  * Do implementations satisfy target device requirements?
>>  * Do implementations achieve satisfactory performance?
>>  * Does the specification satisfy application scenario requirements?

>> It would be better to have the static viewers get a link to an
>> external SVG file from the SVG stub,and have the RCC and script
>> replace that with the dynamic RCC content (again, including the raw
>> XML they are making this from externally).

JL> Whilst I agree this an approach, I've found it not to be too reliable, and
JL> impacts heavily on things like search engines, which are likely not RCC
JL> aware, and almost certainly won't run scripts ever, since the actual content
JL> is then only available by script (although it'll likely index the seperate
JL> SVG image, so all is not lost, but your high quality solution won't appear
JL> in the search results.)

The high quality version won't but the metadata common to both should
be in the stub and so will be indexed.

I agree that search engines are not going to be running scripts, or
fetching external references like other XML, style sheets, or schemas.

 Chris Lilley          
 Chair, W3C SVG Working Group
 Member, W3C Technical Architecture Group

Received on Wednesday, 3 March 2004 05:42:35 UTC