Re: Announcing HLink: rationale

Steven Pemberton wrote:

>     <script src="/scripts/pop" />
> 
> and someone complains that this should use XLink, so it gets changed to:
> 
>     <script xmlns:xlink="http://www.w3.org/1999/xlink"
>         xlink:href="/scripts/pop" xlink:type="simple" xlink:show="embed"
>         xlink:actuate="onLoad" />

Hm... using XLink may make sense but I don't think any of the "embed" 
values do what you want (no surprise, they're aimed at browser-like 
apps) so why provide it?  I'm also not sure that the semantics of 
xlink:actuate are of any real use in this application.

...

>  Oh well, then we have to
> create a brand new extended link element:
> 
>     <secureScript  xmlns:xlink="http://www.w3.org/1999/xlink"
>                    xlink:type="extended">
>         <resource xlink:href="/security/pref1.xsp"
>                    xlink:type="locator" xlink:label="security"
>                    xlink:role="http://example.org/security">
>         <resource xlink:href="/scripts/pop"
>                    xlink:type="locator" xlink:label="script"
>                    xlink:role="whatever" />
>         <resource xlink:type="resource" xlink:label="here"/>
>         <arc xlink:type="arc" xlink:from="here" xlink:to="script"
>                 xlink:show="embed" xlink:actuate="onLoad" />
>         <arc xlink:type="arc" xlink:from="here" xlink:to="security"
>                 xlink:show="embed" xlink:actuate="onLoad" />
>     </secureScript>

Well, if you want to have a markup fragment which contains several 
hyperlinks, each (potentially) with its own assorted metadata, the above 
actually looks like fairly sound markup design to me.

Clearly it could be less verbose without all the questionable embed and 
actuate attributes.  Furthermore, it's not clear that you really need 
the "arc" elements; the traversal rules are probably builtin to the 
application.  But let's say that in this case the application really 
*does* have a good use for XLink's embed, actuate, and arc-traversal 
semantics, and let's grant that the XLink markup is verbose.

> 3) And then along comes the XML Privacy group that introduces the XML
> Privacy specification that says that in order to reference a privacy
> preference file from XML, you have to put a URL ... no let's not do that
> today.

Well yes, let's.  If you grant the basic XML design pattern of using 
elements for repeating whatevers, then you can add the output of as many 
more WGs as you want without busting your design.  You can even add 
links to the links if you need to.

>     <script src="/scripts/pop"
>       xsecurity:preferences="/security/prefs1.xsp"/>

The above looks like rather brittle markup design.  There is no place to 
put any other interesting metadata you might eventually develop about 
the other resources referenced.  I do think that in the general case, 
for multi-ended links, elements make a better design pattern.  But I 
recognize that this burns quite a few more bytes and that others may 
disagree.

> HLink, just released, allows you to define this.
> http://www.w3.org/TR/hlink/

Is it fair to say that HLink is an abbreviation mechanism?  I.e. you can 
have the semantics of XLink without having to have all the markup 
explicitly there.  The price you pay is that your instance is less 
self-descriptive and requires a bit more complexity in processing.  Not 
a hard trade-off to understand.  My personal design bias is for highly 
self-descriptive and simple-to-process markup, but I recognize that this 
feeling may not be universal.

  -Tim

PS: Clearly there is overlap between HLink and the old ISO 
"architectural forms" technology.  If the consensus of the community is 
that they'd prefer to do attribute remapping of the kind Steven 
illustrates above, it's probably worthwhile investigating this overlap. 
  Some time back David Megginson built an excellent lightweight 
XML-centric version of AFs with accompanying software that demonstrated 
very nicely.

Received on Friday, 13 September 2002 20:07:54 UTC