1CD55F04538DEA4F85F3ADF7745464AF1AE50CFC@S-BSC-MBX1.nrn.nrcan.gc.ca"
type="cite">
> I don't understand what this means. For
example, xsi:schemaLocation?
xsi:schemaLocation _is_ a typed
link, the type is implied by the design/context of this
attribute. It's just that
there's no media type apart from
application/xml to go with it.
with an xml-stylesheet PI
which styles the result to HTML. However, most 'properly configured
web servers' would
provide an html
representation and an xml representation, and not use the
xml-stylesheet trick.
different representations
of that resource, and it would be up to the client to negotiate for the
right one. There
would likely be a default
representation, one which would be served in the absence of an Accept
header, or where
the media type ranges
provided by the Accept value could not be honoured. Mostly on the web
this is text/html,
but where the most common
use is in an xml toolchain it makes sense to make the default
application/xml,
as is the case here.
>
The content-type of a resource is independant of any entity which links
to it.
Yes. But there can be
more than one view of that content type.
Cheers,
Peter
> Because there are no typed links in XML so
it is impossible for the
> client to disambiguate except perhaps by context / hardcoding?
I don't understand what this
means. For example, xsi:schemaLocation? If you fetch a document at
that link, or you fetch an XSD document as Roger initially did, any
properly-configured web server will return that with an XML
content-type. The content-type of a resource is independant of any
entity which links to it.
/r$
--
STSM, WebSphere Appliance Architect
https://www.ibm.com/developerworks/mydeveloperworks/blogs/soma/