Open hassanakbar4 opened 5 years ago
@{"email"=>"julian.reschke@gmx.de", "name"=>nil, "username"=>nil} uploaded file foo.xml
(108.5 KiB)
@{"email"=>"henrik@levkowetz.com", "name"=>nil, "username"=>nil} commented
See https://tools.ietf.org/html/rfc7998#page-13, list items 4, 5, and 6.
@{"email"=>"julian.reschke@gmx.de", "name"=>nil, "username"=>nil} commented
None of these steps seem to apply here (also, this is the preptool spec, so if it would define the actual meaning of the grammar, it would be misplaced).
FWIW:
Step 4: If an
Step 5: If an
Step 6: If an
@{"email"=>"henrik@levkowetz.com", "name"=>nil, "username"=>nil} commented
The rest of the quoted text from 7998 says:
6. If an <artwork> element does not have type='svg' or
type='binary-art' and there is an "src" attribute, the data needs
to be moved into the content of the <artwork> element. Note that
this step assumes that all of the preferred types other than
"binary-art" are text, which is possibly wrong.
* If the "src" URI scheme is "data:", fill the content of the
<artwork> element with the correctly escaped form of that data
and remove the "src" attribute.
* If the "src" URI scheme is "file:", "http:", or "https:", fill
the content of the <artwork> element with the correctly
escaped form of the resolved text from the URI in the "src"
attribute. If there is no "originalSrc" attribute, add an
"originalSrc" attribute with the value of the URI and remove
the "src" attribute.
If I were to follow this for
In order to avoid making mistakes by guessing at what the author means in the absence of a type attribute, the type attribute is required. Say that the artwork content is type="svg", and the possibilities of mistakes go away.
@{"email"=>"julian.reschke@gmx.de", "name"=>nil, "username"=>nil} commented
Not true.
The processor clearly can detect whether the content of artwork is just character data or whether it contains an
FWIW, that's also what the grammar says (https://greenbytes.de/tech/webdav/rfc7991.html#grammar.artwork) and the prose (https://greenbytes.de/tech/webdav/rfc7991.html#rfc.section.2.5.p.9>) say. There is no ambiguity here.
@{"email"=>"henrik@levkowetz.com", "name"=>nil, "username"=>nil} commented
And how would you then include literal svg code?
@{"email"=>"julian.reschke@gmx.de", "name"=>nil, "username"=>nil} commented
You would have to escape it, just like HTML or other XML code.
@{"email"=>"julian.reschke@gmx.de", "name"=>nil, "username"=>nil} commented
That said, I can see that it might make sense to issue a warning when there is SVG content and the type says something else.
@{"email"=>"julian.reschke@gmx.de", "name"=>nil, "username"=>nil} commented
opened: https://github.com/rfc-format/draft-iab-xml2rfc-v3-bis/issues/75
@{"email"=>"rjsparks@nostrum.com", "name"=>nil, "username"=>nil} changed status from new
to waiting
@{"email"=>"rjsparks@nostrum.com", "name"=>nil, "username"=>nil} commented
Waiting on xml2rfc-v3-bis.
component_Version_3_cli_txt
type_defect
| by julian.reschke@gmx.deGiven
xml2rfc (with --v3 and --html) says:
This can be worked-around by specifying the type as "svg", but I can't see how RFC 7991 requires this, and it appears to be redundant information when the content is indeed SVG.
Issue migrated from trac:384 at 2021-10-20 18:30:51 +0500