RE: [xml-dev] xml:href, xml:rel and xml:type

["Len Bullard" <Len.Bullard@ses-i.com>]

Let's be fair.  Hytime became Elliot's by award and rightfully given the
work he put into it, but it was being worked some years before Eliot.
In fact, if you have the technical history of Hytime by example, you
have most of everything ever tried in hypertext linking.  The original
drafts are almost identical to what would become web HTML long before it
stopped to REST (again, be fair: REST is a retrofit). Arch forms come at
the end of a long line of good tries.  Timing and luck and implementors:
at the end of the day, it comes down to implementors.

An XML hypertext engine that plays well with REST and ignores undeclared
gencodes is a viable approach if "anyone cares".   It would be a
continual frenetic activity of choosing what to implement and what is
too application-specific to care.    IADS/IDEAS was just that: a fixed
set of tags that then became tag types and eventually a morass of
processing instructions and the rest of straight-up XML before there was
an XML with a style sheet per document type.  No RDBs needed or wanted.

Why do it?  Why do hypertext PDF?

If you want to look at the ultimate complex approach, look at S1000D
where a configuration management approach dominates the design over a
Common Source Data Base.  Lots of money spent but suspended in gaffa
otherwise.  Why?  So far it doesn't solve problems people care about for
the cost of the solution.  John Junod (hey, john) may drop by to pound
me for saying that.

len

-----Original Message-----
From: Liam R E Quin [mailto:liam@w3.org] 
Sent: Wednesday, April 18, 2012 11:20 PM
To: Rushforth, Peter
Cc: Len Bullard; xml-dev@lists.xml.org
Subject: RE: [xml-dev] xml:href, xml:rel and xml:type

On Tue, 2012-04-17 at 12:05 +0000, Rushforth, Peter wrote:
[...]
> Web crawlers, to take one example, can't crawl xml, because there is
no reliable static
> markup to identify links in all xml.

There's also no way to mark what's content, which elements break
phrases, how to make elements bold or italic, which elements are titles,
that Web crawlers need to generate result snippets.

Arch Forms were the HyTime/Eliot-Compatible Approach (HTECA).


>   The existence of xml:href solves that problem.
> Unless they are Kreskin crawlers they won't know what to do with the
xml when they find it.
> That is what @xml:type is there for.  While application/xml does not
tell you too
> much, there are sub sub media types, media type parameters etc to tell
you how
> to process the representation once you retrieve it.  Also, it does not
have to be xml :-).

Media type tells you what something is, not how to process it. There are
lots of things you can do with an SVG image, for example, besides simply
rendering it.

> 
> Finally, applications which use xml on the web need a way to decide /
let the
> client decide what state is the next state for the client.  That is
what @xml:rel 
> is for.
> 
> How is this different from xlink?  For one thing, it is static shared
markup that
> can be reliably used by the entire community.  For another, xlink:type
and xml:type are
> different. xlink:type describes the processing of the link, while
xml:type advertises
> the media type that may be negotiable from the server (no guarantees,
after all its
> the server's resource).

Putting media types in static content is generally not a good
architecture. The remote Web server will send a media type as an HTTP
header and that is what should be used - it is normative,
authoritative. 
This is why, in HTML, it's <a href="foo"> and not <a href="fo"
type="text/html">

Indeed, different HTTP clients (browsers) might receive different
formats, depending on the Accept: HTTP headers they send.

> 
> Why is xml:lang needed for xml itself?  or xml:base for that matter?
> Why is linking less important?

Where you start and stop is fairly arbitrary. We didn't do xml:id in the
first spec either.

Peter, the people you need to persuade here mostly fall into two broad
camps - (1) people happy with XML and namespaces and who generally see
little or no problem with XLink. XLink already has the ability to
describe the "state of the cilent" as you call it, to specify link
relationships (like the rel attribute on "a" and "link" in HTML), and
does not have the Web-architecture-breakage of putting media types into
links ;-)... and (2) people who have no interest in using XML on the Web
today, and for whom the difference between xlink:href and xml:href is
like saying, buy a Jeep because the rear axle leaf spring bushings are
polyurethane whereas in a Toyota they're aluminium.

The biggest barrier to XML on the Web today is that when Aunt Tillie
tries it, and leaves quotes of her attribute values, she gets a really
confusing error message.

The next biggest is lack of architectural forms for search crawlers and
ad servers to use.

Without ads, and with strict syntax, we're not about to take over the
world.

That's actually fine, too. XML is used in televisions, in DVD players,
in music players, in 'plane navigation systems, in shoes, in car
engines, all over the world. OK, not in _all_ shoes, but there were
some. Honest ;)

We are limited in the ways we can change XML itself, although we can
change the layers above more easily.

Liam

-- 
Liam Quin - XML Activity Lead, W3C, http://www.w3.org/People/Quin/
Pictures from old books: http://fromoldbooks.org/


_______________________________________________________________________

XML-DEV is a publicly archived, unmoderated list hosted by OASIS
to support XML implementation and development. To minimize
spam in the archives, you must subscribe before posting.

[Un]Subscribe/change address: http://www.oasis-open.org/mlmanage/
Or unsubscribe: xml-dev-unsubscribe@lists.xml.org
subscribe: xml-dev-subscribe@lists.xml.org
List archive: http://lists.xml.org/archives/xml-dev/
List Guidelines: http://www.oasis-open.org/maillists/guidelines.php