Re: Profiles in SVG 1.2

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



JL> "Chris Lilley" <chris@w3.org> wrote in message
JL> news:369029357.20040303075731@w3.org...
>> 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.
>>
>> http://www.w3.org/TR/2002/CR-SVG11-20020430/

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
http://www.w3.org/2004/02/Process-20040205/tr.html#cfr

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?
http://www.w3.org/TR/2002/CR-SVGMobile-20020430/

>> 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                    mailto:chris@w3.org
 Chair, W3C SVG Working Group
 Member, W3C Technical Architecture Group

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