OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

 


 

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

[ Lists Home | Date Index | Thread Index ]

> 
> 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






 

News | XML in Industry | Calendar | XML Registry
Marketplace | Resources | MyXML.org | Sponsors | Privacy Statement

Copyright 2001 XML.org. This site is hosted by OASIS