RE: Hypermedia - Why

Hi David,

> the one thing I think that xlink in the end (not actually in its initial
drafts) got wrong is using fixed attribute names. 

Is that really so bad?  When we see @href we understand what it is.  If it could
be arranged that @href had a value conforming to RFC 3986, would that not be
useful knowledge?  Same for the other vowels.  XLink does not leverage that fact, except for
href.  As I mentioned, href is the only xlink attribute I've ever seen used, except when forced
to by a schema.  xlink is clearly about perfection, and while I hate to be seen arguing for something
other than perfection, I don't think objects and resources can be reconciled, any better
than they have already been in xml.  So maybe xlink has a use somewhere, but IMHO it's not
because of the colons in the names *or* the fact that you can't have two hrefs on the same element
that it is not workable.

For example, Atom Publishing protocol makes use of various hypermedia constructs, including
links and forms.  For multiple links, it allows (encourages) multiple <link> elements.
The <collection> (form) element has an @href and I think there are probably other examples.  It doesn't
use @method, because I think it has tried to keep it simple (Tim Bray was involved, so I imagine
that the motto was something like: what's the simplest thing that could possibly work?).

> XML isn't in itself a language, it is a framework for 
> designing languages

Well, what we design with XML aren't really languages, are they?  Maybe vocabularies would be
more appropriate.  Either way, vowels is the thing I think we're talking about here.   And that's exactly
the point, XML should give the users of that framework the tools to design their vocabularies 
appropriate to the environment.  Schemas and namespaces are one way.  The other way is the
the way I'm proposing.

Atom, for instance,  does not use a schema, per se, just a public specification with required / permitted
content layout.  I would say it is a best practice for hypermedia design. 

But success on the web is not just tied to the value of the href, or URI, it is related to four
key constraints:

REST constraint                    (proposal elements which apply)
==================================================================
URIs                               (href, src)
manipulation of resources
 through representations,          (type,hreflang)
self-descriptive messages          (type,method)
hypermedia as the engine 
 of application state              (type,rel,hreflang,method,tref)

Obviously URIs apply to all aspects of the definition of REST, whether the link is outbound
or inbound.

> But the default position for _any_ suggestion to increase the 
> number of pre-defined names should be not to do it. The bar 
> for adding names to the xml namespace should be incredibly 
> high. The xml: namespace allowed a few small exceptions to 
> the general principle that names should not be reserved.

As long as it is not the _only_ position, we can still talk.

> As I mentioned before, these reasons alone were the reasons 
> for not using xlink on languages such as xhtml2 being 
> developed at the time.

> Chinese) or, closer to home, if all your attribute names did 
> not have a colon. 

Well, I imagine "xml" happens to show up in the Chinese xml 
from time to time, and what about xmlns etc?  A little bit more won't hurt.  

> It also means (since only one such name is 
> allocated) that you can not have two such attributes on the 
> same element.

We should ask the
hypermedia community what *they* think.  Not the XML community, strictly, although
there is obviously an intersection.

> If you want to say attribute foo="example.com" is a link of a 
> certain type, you should define a schema type representing 
> that and then apply that schema to the instance. (Or if not 
> XSD specify a different annotation mechanism). What you 
> should not do is say "if you want to make a link the 
> attribute has to have fixed name xxxxx".

I personally have nothing against XSD, nor schemas of any kind in general.  In fact,
the bugzilla bug I wrote included a schema to describe these vowels.  I'm a pointy bracket 
guy!  But I think schemas and namespaces are what we want to avoid in this case.
If you want to do that with your vocabulary, so as to have control over the names of
attributes, elements, what have you, go ahead, the facilities are there already in XML.
What we want here are some hypermedia affordance vowels which reflect the 
architectural style of the web, as we know it today, and that we can refer to in
our vocabularies, _by specification_, not schema.

I believe the community should be consulted on that, definitely.

I enter a couple of blog posts into evidence:

http://www.tbray.org/ongoing/When/200x/2009/04/29/Model-and-Syntax#p-1
http://www.mnot.net/blog/2012/04/13/json_or_xml_just_decide

And this is not about JSON, like I said, I'm a pointy bracket guy :-).

Peter

Received on Friday, 27 July 2012 10:05:20 UTC