[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message]

Re: [Fwd: The problems with Xlink for integration languages]

• To: Joe English <jenglish@f...>
• Subject: Re: [Fwd: The problems with Xlink for integration languages]
• From: Uche Ogbuji <uche.ogbuji@f...>
• Date: Thu, 19 Sep 2002 07:32:17 -0600
• Cc: xml-dev@l...
• In-reply-to: Message from Joe English <jenglish@f...> of "Sun, 15 Sep 2002 11:30:02 PDT." <200209151830.g8FIU2326367@d...>
• Sender: uche.ogbuji@f...

> 
> Uche Ogbuji wrote:
> 
> > > [Joe English]
> > > [Re: http://www.w3.org/TR/hlink/ ]
> > >
> > > Initial impression:  This looks OK.  It finally reinvents
> > > architectural forms in a way that's usable in XML.
> >
> > I'm surprised to hear you say this.  HLink looks more about annotating
> > attributes for presentation semantics than any form of remapping or
> > vocabulary-level adaptation.
> 
> That's not surprising, since most of the semantics
> added by HLink _are_ presentation-oriented.

Agreed, but that wasn't the matter I was emphasizing.


> But there is a small kernel, sort of a design pattern,
> that could be reused in other architectural vocabularies.
> The key pieces are the declaration element (hlink:hlink),
> and the 'namespace' and 'element' attributes; all the
> other hlink:hlink attributes are treated uniformly by
> the remapping process.
> 
> Other vocabularies could reuse this technique by specifying
> their own declaration elements, which would work the same
> way.

Hmm.  I don't see anything in HLink that would encourage me to follow suit if 
I wanted to do some vocabulary adaptation of my own.  Basically, I think 
you're saying HLink is a very weak sort of exemplar of the beginnings of a 
hypothetical approach to AFs in XML (;-) ).  I suppose I could by that, but I 
don't know why it's significant since any number of other arbitrary 
vocabularies can be seen the saem way.


> > > (XLink started to do this, but the omission of any kind
> > > of attribute renaming facility and the lack of a reliable
> > > attribute value defaulting scheme made XLink inflexible
> > > and difficult to use, as Steve Pemberton's message convincingly
> > > described.  The 'hlink' declaration scheme solves both those
> > > problems.)
> >
> > Ah.  I don't see any attribute renaming in HLink.
> 
> For example:
> 
>     <hlink:hlink element="img" locator="@src"/>
> 
> means, roughly, that the 'src' attribute of an 'img' element
> is to be treated as the 'locator' attribute of an 'xlink:simple'
> element.  It's basically the same as the AFDR declaration:
> 
>     <!ATTLIST img
>     	XLinkNames	#FIXED "src locator"
>     >
> 
> (where XLinkNames is the "Architectural attribute renamer" attribute.)

I find this hard to accept.  It seems that by this thinking, any vocabulary 
that is a variant of another can be seen as an attribute remapping.

Maybe I misunderstand you, but I still see no real attribute mapping in HLink.


-- 
Uche Ogbuji                                    Fourthought, Inc.
http://uche.ogbuji.net    http://4Suite.org    http://fourthought.com
Apache 2.0 API - http://www-106.ibm.com/developerworks/linux/library/l-apache/
Basic XML and RDF techniques for knowledge management, Part 7 - http://www-106.ibm.com/developerworks/xml/library/x-think12.html
Keeping pace with James Clark - http://www-106.ibm.com/developerworks/xml/library/x-jclark.html

• References:
  • Re: [Fwd: The problems with Xlink for integration languages]
    • From: Joe English <jenglish@f...>

• Prev by Date: Re: Push / pull model
• Next by Date: RE: Don't Let Architecture Astronauts Scare You
• Previous by thread: Re: [Fwd: The problems with Xlink for integration languages]
• Next by thread: RE: [Fwd: The problems with Xlink for integration languages]
• Index(es):
  • Date
  • Thread