Lists Home |
Date Index |
- To: "Joe English" <email@example.com>,<firstname.lastname@example.org>
- Subject: RE: [xml-dev] Rethinking namespaces, attribute remapping (was Re:[xml-dev] TAG on HLink)
- From: "Dare Obasanjo" <email@example.com>
- Date: Fri, 27 Sep 2002 09:36:17 -0700
- Thread-index: AcJmQZoBmASiq+8kTD6rRCDfeqbh2gAAZS5Z
- Thread-topic: [xml-dev] Rethinking namespaces, attribute remapping (was Re:[xml-dev] TAG on HLink)
We must have read different working drafts because your interpretation of how HLink is intended to be used is different from what I gathered from reading the HLink WD. If what you say is the case, then HLink is rather useless and the HTML working group might as well just hard code the meanings of the links into the XHTML 2.0 working draft's prose.
As for your comments about producers and consumers sharing knowledge about how to process a vocabulary you seem to be mixing up how XML is used in data interchange scenarios with the WWW. On the WWW there are no prearranged agreements between myself and Google when I do a HTTP GET for its front page.
From: Joe English [mailto:firstname.lastname@example.org]
Sent: Fri 9/27/2002 9:14 AM
Subject: Re: [xml-dev] Rethinking namespaces, attribute remapping (was Re:[xml-dev] TAG on HLink)
Dare Obasanjo wrote:
> 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_
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.
The xml-dev list is sponsored by XML.org <http://www.xml.org>, an
initiative of OASIS <http://www.oasis-open.org>
The list archives are at http://lists.xml.org/archives/xml-dev/
To subscribe or unsubscribe from this list use the subscription