"Maybe RDF should not have followed the naming convention '+xml'."
Hmm... perhaps not. Hmm...
--
Dan Connolly, W3C http://www.w3.org/People/Connolly/
Forwarded message 1
Chris Lilley <chris@w3.org> wrote:
> MI> However, I'm not quite sure whether this is really applicable to
> MI> 'application/rdf+xml' [2]. What does #element(/1/2) mean in
> MI> 'application/rdf+xml'?
>
> Its very clear what it means. Its not at all clear that it is a useful
> thing to point to.
;-)
> MI> Is there any conflict between RDF's concept
> MI> of fragment identifiers [3] and this requirement?
>
> There isn't a conflict, in that application/rdf+xml can add its fragid
> syntax to the +xml fragid syntax.
Well, the following paragraph:
If an XML-based media type requires a fragment identifier syntax
other than XPointer, the media type SHOULD NOT follow the naming
convention '+xml'.
made me wonder whether rdf:ID and rdf:about are compatible with XPointer.
As far as I heard, an RDF "ID" is NOT an XML ID, so it won't be
compatible with shorthand pointer. Maybe RDF should not have followed
the naming convention '+xml'.
> There may be a conflict in
> implementors saying they don't want to add the +xml fragid syntax. Or
> there might be support from implementors who like to have a uniform
> fragid syntax in a multinamespace, comound documents scenario.
Actually how fragment identifiers work in compound documents is my
another question. SVG supports fragment identifiers like
#xpointer(id('MyView')) in 'image/svg+xml' [4], but when an SVG image
is served as 'application/xml', what should happen? It just doesn't
work? How about SVG in XHTML served as 'application/xhtml+xml'?
'application/xhtml+xml' doesn't support the XPointer xpointer() scheme,
so it shouldn't work, either?
Probably these issues are outside the scope of this I-D, but should
there be a Working Group on compound documents, they should consider
these cases, IMHO.
P.S. Just out of my personal interest, I created a few test cases [5].
The index document itself is an XHTML document served as
'application/xml', and it contains document-internal references
using shorthand pointers as well as the element() scheme. It also
includes links to an SVG document which includes an XHTML fragment,
and an XHTML document which includes an SVG fragment, both using
its own media type ('image/svg+xml' or 'application/xhtml+xml') and
'application/xml'. You'd need a browser that supports a combination
of SVG and XHTML, as well as the XPointer Framework and the element()
scheme - which effectively means SVG-enabled Mozilla would be
the only possibility at the moment. At first glance, the element()
scheme works for 'image/svg+xml' as well in Mozilla, but it doesn't
work for 'application/xhtml+xml' due to a bug [6].
> [1] http://www.rfc-editor.org/rfc/rfc3236.txt
> [2] http://www.ietf.org/internet-drafts/draft-swartz-rdfcore-rdfxml-mediatype-05.txt
> [3] http://www.w3.org/TR/2004/REC-rdf-concepts-20040210/#section-fragID
[4] http://www.w3.org/TR/SVG11/linking.html#SVGFragmentIdentifiers
[5] http://www.w3.org/2004/07/xml-fragid-test/
[6] http://bugzilla.mozilla.org/show_bug.cgi?id=235409
Regards,
--
Masayasu Ishikawa / mimasa@w3.org
W3C - World Wide Web Consortium