Closed GoogleCodeExporter closed 9 years ago
[deleted comment]
[deleted comment]
[deleted comment]
[deleted comment]
Original comment by markus.g...@gmail.com
on 27 Mar 2013 at 9:39
Original comment by mgarrish
on 28 Mar 2013 at 8:57
We should also allow SVG elements to have the prefix attribute in the
namespace
http://www.idpf.org/2007/ops for vocabulary association.
Original comment by eb2m...@gmail.com
on 6 May 2013 at 12:25
Makoto, the WG discussed this on the 0718 call. The question to you, since SVG
already allowed attributes in foreign namespaces, is whether you agree that it
would be enough to add prose to the SVG section of the ContentDocs specs that
say something along the lines of "If the attributes epub:type and epub:prefix
occur on SVG elements, they must be interpreted as defined in this
specification".
Original comment by markus.g...@gmail.com
on 31 Jul 2013 at 11:12
I read "2.1.3.1 Semantic Inflection" in the ContentDocs
spec. Do we allow the epub:prefix attribute in some
HTML element to define prefixes in epub:type attributes
of in-line SVG elements?
To clarify such edge cases, I think that we need three
changes
1) slightly change 2.1.3.1 for SVG elements in HTML content docs;
2) create a new subsection in "2.1.4.2. Embedded SVG" for epub:type; and
3) copy 2.1.3.1. Semantic Inflection to "2.3 SVG Content Documents"
Original comment by eb2m...@gmail.com
on 10 Aug 2013 at 7:35
I believe the intent was that @epub:prefix was only valid on the root html
element, the same way it is only valid on the root package element, for
processing simplicity. We could make that more explicit, but that's how the
schema defines its use.
Adding a 2.1.4.2.2 for semantic markup that indicates that both epub:type
and RDFa attributes are allowed on embedded SVG could be done for clarity,
but as Markus notes these are allowed whether we say so or not. It might be
worth clarifying whether @prefix is also allowed on the root svg element
when embedded, though. I'm thinking it should be allowed, but not required,
for consistency with standalone svg.
For 2.3 I'd recommend just pointing to the section in xhtml, noting that
the mechanisms and default vocabulary are the same, rather than redefine
everything again, since all we're doing is allowing the attributes
(technically semantic inflection should be standalone and referenced by
both xhtml and svg, but that would be a bigger change). Maybe this
requirement could even be done as a content conformance bullet rather than
a full new section?
Original comment by mgarrish
on 10 Aug 2013 at 1:13
Matt, thanks for your observations about permissible locations of the prefix
attribute. It makes sense to allow it for the html and svg elements and
nowhere else.
We might want to create a new section (before "2. EPUB Content Documents")
for semantic inflection rather than in SVG or HTML, especially because we
might want to allow epub:type for MathML.
Original comment by eb2m...@gmail.com
on 10 Aug 2013 at 1:38
And scratch RDFa from my comment in #10. I don't believe those can be used in
SVG 1.1 since they aren't in a separate namespace (SVG 1.2 introduces them as
core attributes).
Original comment by mgarrish
on 29 Aug 2013 at 3:00
Specification has been updated as resolved on the 2013-08-29 telecon:
https://code.google.com/p/epub-revision/source/detail?r=4720
For review:
Restricting epub:prefix to the root html element in the existing semantic
inflection section:
https://epub-revision.googlecode.com/svn-history/r4720/trunk/build/301/spec/epub
30-contentdocs.html#sec-contentdocs-prefix-attr
New semantic inflection section for SVG:
https://epub-revision.googlecode.com/svn-history/r4720/trunk/build/301/spec/epub
30-contentdocs.html#sec-svg-semantic-inflection
Original comment by mgarrish
on 30 Aug 2013 at 9:03
Original comment by markus.g...@gmail.com
on 4 Sep 2013 at 9:49
Original issue reported on code.google.com by
eb2m...@gmail.com
on 20 Feb 2013 at 4:13