RE: Hypermedia - Why

On July 25, 2012 08:59, David Carlisle wrote:
> 
> On 25/07/2012 13:33, Rushforth, Peter wrote:
> 
> >> If it is for encoding hypertext why is it important to have a 
> >> domain-agnostic markup for a link but not for a paragraph?
> >
> > <p/> you mean?  Isn't that domain-agnostic?
> 
> No. Not in the sense you were using the terms (if I 
> understood them at all). XML doesn't define any markup for 
> paragraphs (p is defined in for example xhtml) and it doesn't 
> define any markup for links (href for example is defined in xhtml).

OK.  XML does not define the meaning any vocabulary, apart from a few (well) chose attributes.
The "domain" of at least one of those attributes is "The Web" (xml:base), so while
it's not strictly domain-agnostic, its domain is 

> 
> You are suggesting moving the definition of links to a core 
> xml "domain-agnostic" layer rather than being defined in a 
> specific language such as xhtml.

Yes.

> What I don't see is why links are special. Why don't you want 
> to do that for paragraphs, or titles or any other part of hypertext?

Well, I wouldn't mind, but I think the XML namespace might get rather large ;-).
But that is a separate discussion, I think under MicroXML.

> 
> If xml had xml:href what use could you make of a document if 
> you did not know what any of the elements meant but did know 
> that some of the attributes were hypermedia?
> 
> So you are given
> 
> <xxxxx xml:href="foo.bar">
> <yyyy xml:tref="abc$3"/>
> </xxxxx>
> 
> If you don't know the <xxxxx> means comment and the element 
> should be ignored, what use can you make of knowing that 
> xml:href is a reference?

Well, your media type might say that the reason for a comment is explained
by the html page which could be negotiated from xml:href="foo.bar" xml:type="text/html".
But, you don't strictly have to know what <xxxxx> means in order to know what xml:href means.

> 
> If you have to know what <xxxxx> means before you can 
> interpret the markup 

The markup yes.  The related resource, no
At a minimum, you only have to understand the fact that another resource is related to this one.

> then you can only interpret the links if 
> you already know the domain language being used, in which 
> case (as in XHTML) it would be simpler if that language just 
> defined href="foo.bar" or other markup appropriate to that language.

text/html also has xlink:href in it now, I think.  So now there are
two link forms.  application/xml would only have xml:href.

But yes, if we could somewhere say that href et al were the *only* way
to encode links and link metadata, then I think that would work.  But
I don't think there is currently any way to nail those down enough to 
be reliable outside their home media type definitions.  And if the definitions
are multiple, then there is no way to nail the meaning down.  So, back to the beginning.

> 
> Please take this as a real example, as I think I can't see 
> how these xml hypermedia attributes could be used unless they 
> mean something in this case.

The meaning of the attributes would be strictly defined by reference to a standards-track RFC.

> 
> 
> >
> > If you mean, why would you need xml:href etc in a domain specific 
> > media type, the answer is, IME, because this part of the markup is 
> > specific to connections between web resources, and the 
> infrastructure 
> > of the web is organized around connections between resources.
> >
> > So a web of data can contain any old data connected by 
> > connection-specific markup.
> >
> >>
> >> There needs to be at least one use case where having this 
> helps and 
> >> would work better (or even as well as) using xhtml and the link 
> >> markup.
> >
> > What link markup are you referring to?
> 
> any markup that should end up being specified by this CG.

I think we need to discuss each hypermedia vowel individually, because I sure am not
100% familiar with the various RFCs that I've pointed them to.

Additionally, xml:tref is *new*.  The only other template attribute I have seen is
@template in opensearch, and I thought it was too far away recognition-wise from 
href, and too many characters.

David, I apologize if my answers are off the mark.  I will try to improve them,
and I will certainly try to avoid talking across you without listening.  But sometimes,
I just don't understand, and I need to go over the ground a bit to be sure that I do.

Peter

Received on Wednesday, 25 July 2012 14:00:07 UTC