Re: document types in retrieving "information about me"

> > In HTML the use of the LINK element seems to be
> > appropriate for linking to the report, there are certainly
> > no others within the current recommendations.

Before I get to Al's rant about <link>, I'll add my own, previously
unarticulated, comments.

The idea of separating literal valued data from URI-reference valued data
is useful, and compares to what was done in RDF, the "de facto" (triple
quote it) metadata standard. The head[@profile] attribute adds value in
that both meta[@name] values and the link-types datatype are contained
within the profile space. HTML does not say how they are contained within
the profile space. This is comparable to the fact that the XML Namespace
specification does not actually reveal the structure of namespaces. It
leads, in some senses, to broken Web architecture, as people start to
define - by specification - the workings of the QName (which is also what
the profile/value couplets in HTML are, when you think about it), rather
than by documentation, or by machine readable assertion.

The HTML link type system is a step more broken, because in some
situations, link types used in conjunction with others "mean" special
things. e.g. "alternate stylesheet". The same goes for an "alternate" link
value used in conjunction with a language value (@xml:lang). This is a
terrible way of going about things if you want to port to machine
readability, because it means you start having to come up with complex
predicates almost immediately, and build a case exceptions list for the
patterns which don't fit.

Indeed, I already ended up having to do this in my latest "RDF-from-XHTML"
attempt, and that forms the basis for the rant; this is based on
conclusions from a practical experiment. The conclusions is that LINK and
META are just poor bits of metadata kit; weak extensiblity, and a mess of
custom semantics.

[...]
> > "Authors may use the following recognised link types, listed
> > here with their conventional interpretations. - -"

That implies semantics that are dynamic, and based upon the context of
use/processing. Ugh.

[...]
> The META syntax is limiting in having only one name-value pair
> at a time.  The ideal thing here is something on the order of
>
> <META KEYWORDS="<list>" HREF="<uri-reference>">
>
> This would indicate that for more meta-information in any of the
> concern areas mentioned in the list of keywords, it would be
> suggested to process the resource indicated in the HREFed
> resource.

By "<list>", I presume you mean a space separated list of NCNAME tokens, or
something along those lines? In that case, you would need to have processor
recognition of those values in order to come to the next part of the
process, which is that I want to know more about this "topic", dereference
the HREF. Perhaps a list of QNames would be better? It gets messy from
there on in; I wrote an XSLT parser once to process multiple QNames, so
once again, this is based on practical experimentation.

> What one perhaps wants is the same effect in a LINK.
>
> <LINK ROLE="meta" HREF="resource" A-PROPOS-DE="<keywords list>">
>
> The availability of processors for languages which are somewhat
> self-defining, that is to say which include definitions for the terms
> they use, is a hot issue.  Relevant here, and controversial in the
> community.

Very much so. But I won't repeat too much of the discussion here, seeing as
how we've iterated through it many many times on RDF IG etc.

> [...] X-Link exists as a generic utility in XML,

XLink is another story, but now you mention it...

* The "role" attribute is great, but it corresponds directly to "rel" in
HTML. O.K., so, where's the "rev" equivalent gone to?
* The datatype value of "role" is basically xsd:anyURI. That's rather
offputting: QNames that resolve to URI-references a la RDF may be
controversial, but they are still sensible to investigate in an XML
environment.

This is another thread that could run off at a tangent.

[...]
> The proposal that I am working on is that
>
> a) the element that cites the report indicates why you would be
> interested in what it says.  So the "accessibility evaluation results"
> semantic is somehow in the LINK mode or other syntactic slots
> in the citation expression.

Heh, "somehow" :-)

> b) [...] In particular, schema citations are an area where a
> binding type indication may be appropriate.

It is appropriate in any case where there is no magic formula for a
document type. One example is NQuads: where the extra term could be a
statement ID or a context flag! So:-

   _:a _:b _:c _:d .

may be very different to:-

   _:a _:b _:c _:d .

Ah... extensions of RDF.

> The idea that the HTTP indicated Content-Type property defines
> all the type knowledge about the content forever and aye is rejected.

Yes! I'm very glad to read that. It's not as if extensible languages have
sprung up overnight, but XML and RDF really do change the way that we think
about "x is of format y", because now the semantics, or whatever mechanism
the instance is trying to express is not necessarily bound to the
serialization itself. That is always true for RDF, and it may be true for
any given "dialect(?)" of XML.

> So long as the syntactic processing can be completed in
> accordance with the [super-] type [...]

As contrasted against [syntax-] type?

Cheers,

--
Kindest Regards,
Sean B. Palmer
@prefix : <http://webns.net/roughterms/> .
:Sean :hasHomepage <http://purl.org/net/sbp/> .

Received on Saturday, 20 October 2001 13:27:50 UTC