W3C home > Mailing lists > Public > www-svg@w3.org > September 2004

sXBL: Dynamic Conformance Constraints

From: Bjoern Hoehrmann <derhoermi@gmx.net>
Date: Sat, 11 Sep 2004 04:09:46 +0200
To: www-svg@w3.org
Message-ID: <415e5a48.619120988@smtp.bjoern.hoehrmann.de>

Dear Scalable Vector Graphics Working Group,

  In the latest sXBL Working Draft, the term "in error" is defined as
follows:

[...]
  In this specification, the term in error, when used of an element
  or attribute, means that the element or attribute is not conformant
  according to the rules of this specification.
[...]

and than uses this term e.g. in section 2.6

[...]
  If the URI designated by an import element cannot be resolved, or
  returns an HTTP 404 error, or does not point to a resource with an
  XML MIME type, or has any other problem that makes it unusable, then
  the element is in error.
[...]

I assume a non-conforming element renders a sXBL fragment non-conforming
which renders the SVG document that includes it non-conforming. Thus, it
depends on the capabilities of the implementation whether SVGs documents
are considered connforming or not, e.g. if the URI refers to a scheme
that the implementation does not support. That would make little sense.
I am thus not sure how Conformance is defined in sXBL, there is section
1.3 on Conformance but it only talks about document conventions. I think
this is misleading and the section should be renamed to, for example,
"Document Conventions".

I do not know why there is no clear definition for document (or sXBL
fragment) conformance, but in general I feel that document formats and
document fragment formats should have a notion of conformance that is
independent from implementation details and dynamic conditions and the
sXBL specification should include such a definition, it would otherwise
only be possible (and even then only in a limited sense) to assess the
compliance of a sXBL fragment if sXBL is implemented.

regards.
Received on Saturday, 11 September 2004 02:10:30 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 5 February 2014 07:14:55 UTC