W3C home > Mailing lists > Public > www-svg@w3.org > October 2008

Re: [LC] Official SVG Tiny Working Draft Comments from W3C RDF in XHTML Task Force (ISSUE-2097)

From: Doug Schepers <schepers@w3.org>
Date: Thu, 09 Oct 2008 23:39:19 -0400
Message-ID: <48EECE67.7020304@w3.org>
To: Manu Sporny <msporny@digitalbazaar.com>
CC: SVG WG <www-svg@w3.org>, RDFa mailing list <public-rdf-in-xhtml-tf@w3.org>

Hi, Manu-

Thanks for your comments.  We have put them in our tracker as
ISSUE-2097.  We will discuss your comments and get back to you promptly.

Regards-
-Doug

Manu Sporny wrote (on 10/9/08 11:06 PM):
> The following are official comments from the RDF in XHTML Task Force
> related to the latest SVG Tiny Working Draft located here:
> 
> http://www.w3.org/TR/SVGMobile12/metadata.html#MetadataAttributes
> 
> The comments revolve around the re-use of RDFa attributes in SVG, which
> we are very pleased to see, but feel that there should be specific
> direction on how those attributes are used.
> 
> Re-use of RDFa attributes should follow RDF in XHTML processing rules
> ---------------------------------------------------------------------
> 
> http://www.w3.org/TR/SVGMobile12/metadata.html#MetadataAttributes
> """
> SVG includes several attributes that may be placed on any element, for
> the use of attribute-based metadata formats. These include the 'class',
> 'role', 'rel', 'rev', 'about', 'content', 'datatype', 'property',
> 'resource', and 'typeof'  attributes. ***SVG makes no specific
> requirements about the values for these attributes, other than their
> particular value data types, such as a string or a space-separated lists
> of strings.*** Other specifications, such as RDFa [RDFA], Microformats
> [MF] patterns, or ARIA [ARIA] ontologies,
> """
> 
> The current text leaves far too much room for mis-use and abuse of the
> RDFa attributes. It would be a shame if authors were allowed to
> re-define how a non-RDFa parser may use those attributes in such a way
> as to directly conflict, or even worse, create ambiguity with regard to
> the current RDF in XHTML parser rules. The RDFa task force went to great
> lengths to ensure that the RDFa Syntax Processing[1] rules define clear
> behavior when RDFa is used in non-XHTML languages.
> 
> Please add text clearly stating that if one re-uses the RDFa attributes
> that they follow the same processing rules as outlined in the RDFa
> Syntax Processing Rules[1].
> 
> @rel/@rev values do not necessarily need to be prefixed
> -------------------------------------------------------
> 
> http://www.w3.org/TR/SVGMobile12/metadata.html#MetadataAttributes
> """
> When used with RDFa, the values for the 'rel' and 'rev' attributes must
> be a CURIE [RDFA] (i.e., a prefixed string, such as 'cc:license' to
> indicate a Creative Commons license), while the values may simply be
> from a set of specific keywords for Microformats. These formats may be
> used independently, or in combination if the keywords do not clash.
> """
> 
> The @rel/@rev values in RDFa can either be a reserved word or a CURIE as
> defined in the RDFa Syntax document[2]. Perhaps the SVG Tiny document is
> authored to not support reserved words due to a mis-reading or
> mis-understanding of the current CURIE specification[3]? The current
> specification allows both prefixed and unprefixed "reference only" values:
> 
> http://www.w3.org/TR/curie/#s_syntax
> """
> curie       :=   [ [ prefix ] ':' ] reference
> ...
> A host language MAY interpret a reference value that is not preceded by
> a prefix and a colon as being a member of a host-language defined set of
> reserved values. Such reserved values MUST translate into an IRI, just
> as with any other CURIE.
> """
> 
> We urge the SVG WG to not limit CURIEs and provide a CURIE mechanism as
> defined by the CURIE specification. It would make the job of RDFa parser
> authors much easier as there are less special cases to consider when
> creating their parser. The current language in SVG Tiny requires all
> current RDFa parsers to strip out all reserved word processing in order
> to conform to SVG+RDFa, which would lead to two increasingly divergent
> types of RDFa parsers:
> 
> 1. Parsers that parse SVG+RDFa 1.0.
> 2. Parsers that parse "XHTML+RDFa 1.0".
> 
> The SVG Tiny document seems to insist that terms must be of the form
> "x:y", instead of also allowing things like "license" (note that there
> isn't a preceding colon before a reserved word).
> 
> We are currently working on a method to specify reserved words that will
> not need preceding colons and the current language in SVG Tiny would
> prevent that method from being used in SVG Tiny.
> 
> Please do one of the following:
> 
> * Adopt the current RDFa/CURIE processing rules as-is.
> * Define a set of reserved words that should be used in SVG Tiny and
>   preserve the functionality provided in the CURIE Specification.
> * Do not rule out the ability to use non-colon-prefixed reserved words.
> 
> @role should follow rules defined in XHTML 1.1 Role Module
> ------------------------------------------------------------
> 
> This is not an official comment from the RDF in XHTML Task Force and
> will probably be mentioned by the XHTML WG. Mark, Shane and Steven were
> on todays RDFa telecon and had issues with the lack of specifics as to
> how an author could use @role. Just a heads up that they would like to
> see it clearly stated that use of @role should follow the specifics
> outlined in the XHTML Role Attribute Module[4]. We want to make sure
> that authors are not under the false assumption that they can put
> whatever they want to in the @role attribute.
> 
> Thanks to the SVG WG in advance for consideration of these issues. We
> are looking forward to using RDFa-based semantics in SVG Tiny. Keep up
> the great work! :)
> 
> -- manu
> 
> [1] http://www.w3.org/TR/rdfa-syntax/#sec_5.5.
> [2] http://www.w3.org/TR/rdfa-syntax/#relValues
> [3] http://www.w3.org/TR/curie/
> [4] http://www.w3.org/TR/xhtml-role/
> 
Received on Friday, 10 October 2008 03:39:28 GMT

This archive was generated by hypermail 2.3.1 : Friday, 8 March 2013 15:54:40 GMT