PR SVGT1.2 - id or xml:id?

Hello SVG WG.

It is now mentioned in the PR:
'Because they are intended for different environments, 
the 'id' and 'xml:id' attributes must not be used together 
on SVG elements in the same document. 
Such documents are not conforming SVG 1.2 Tiny content, 
and the behavior is not specified.'

In the previous drafts was mentioned:
'It is strongly recommended that SVG generators only use 'xml:id' 
to assign identity to elements. For backwards compatibility purposes, 
one may also specify the 'id' attribute ...'
and some more rules.


1. Note, that in the test-suite 
animate-elem-218-t
explicitly tests the previously specified behaviour.
Several other tests (I provided) use both identifiers
to get the mentioned backwards compatibility as specified
in the previous drafts.
With the current wording of the PR the test(s) need to
be removed, because they are not conforming anymore.


2. Most of the other tests use only xml:id and no id.
With the current wording all these tests are now 
mainly intended for 'generic XML processing tools'
and not for 'existing user agents' - note, that
according to the test statistics there are 
obviously several 'existing user agents' passing
many tests, which have only xml:id and no id,
therefore the assumptions seems not to fit.


3. Concerning the suggested XSLT, it is not obvious,
who should do the transformation.

a) The author? The author cannot know, which 
programs will try to present the content in the
future. Therefore the author has to provide
the XSL-file always additionally to the document? 

For example in the chapter about metadata is 
mentioned, that an author should specify
the RDF subject with 'about' if it is only
a fragment of the document. For this it is
obviously more useful to specify xml:id instead of id,
because with the language independent identifier
the subject can be identified by any XML processor,
what might be sufficient for the identification
of machine readable metadata.
Older viewers might need the id at the same
time to render the content. Both applications
are possible at the same time and the authors
cannot predict, which variant is required
at the moment, the document is interpreted.
Therefore the author cannot do the XSLT.
Or has the author always to provide both
variants with some content negotiation?
How is this done?


b) If send by a server, should the server do
the XSLT? Or the content negotiation?
Is it unambiguously possible for the
server to determine, which variant is better for
the user agent asking for the file? If not,
it is not possible, that the server does the
transformation properly.


c) The user-agent? There are neither specific
feature strings for id and xml:id available, as
far as I can see, nor is there a method in 
SVGT1.2 to provide stylesheets with conditional
processing.
Additionally it is mentioned in the styling
chapter:
'Authors must not rely on external, author stylesheets'


d) The user? How is the user informed, that an
XSLT is required to get a usable variant of a
document? And is it required, that the user has
a tool to do the XSLT? If the user is a robot
looking for meta information, is such a user 
required to do an XSLT to find the meta 
information?



4. With the SVG tiny 1.2 documents, I already
have created with both id and xml:id in it with
the same value, I never had a specific problem.
In contrary it was possible to test or to compare
the behaviour of older viewers like the adobe plugin 
too.
There are more complex dependencies in the 
draft than that between id and xml:id, for example
those for rx and ry on each other and on width
and height of a rect. This seems to be no problem,
why is there a problem with id and xml:id
on the same document?






To resume, I think, the possibility to provide
both attributes with the same value as mentioned
in the previous versions is more helpful for
authors to solve real problems and more convenient 
for the final user of the document.
The current wording, that such documents are
not conformant in the current PR does not solve
any problem I can see.
And if there is a problem in the DOM (as 
mentioned/assumed previously in the mailing list), 
it seems to be a better idea to fix the problem 
in the DOM in a similar way as the dependency 
rules for rx and ry seem to be no specific 
problem.



Olaf

Received on Monday, 1 December 2008 13:59:31 UTC