[
Lists Home |
Date Index |
Thread Index
]
Dare Obasanjo wrote:
> SECURITY/PRIVACY:
> HLink requires you to fetch a mapping file from a specified remote location w
> hile XLink does not. Any web page that can make your browser make HTTP reques
> ts other than the ones directly specified by the user are potential security
> and privacy issues. For instance, I can imagine WebBugs going upscale and dre
> ssing themselves up to look legit by using HLink.
Hm. I didn't think HLink was intended to work that way.
I thought the intent was something like: someone developing
a new XML vocabulary wants to include HLink semantics,
so includes an HLink mapping along with the rest of
the vocabulary specification (schema, documentation, etc.)
Application developers who want to use the new vocabulary
consult the HLink mapping when building their own application.
Something like how WSDL works -- web service clients don't
download WSDL at runtime, the _developer_ does when _building_
the client.
Of course with this approach generic web browsers can't
automatically discover the HLink links in arbitrary XML files,
but it's not clear that this is even a requirement.
We don't expect browsers to automatically figure out how
to process *any* random XML documents they happen to download,
only the ones that use a supported vocabulary.
> SELF-CONTAINED INFORMATION:
> In disconnected scenarios or situations where the document is being read by a
> human all the information about the document is not readily available. Thus
> complete processing cannot be done on such a document without retrieving more
> documents which may or may not be available (network issues for instance).
Again, I don't think this is even a requirement.
_No_ XML document is completely self-contained;
we always rely on the producer and consumer sharing
some knowledge of how to process the vocabulary.
--Joe English
jenglish@flightlab.com
|
