[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: xml-dev@l...
• Subject: Re: [Fwd: The problems with Xlink for integration languages]
• From: Arjun Ray <aray@n...>
• Date: Sat, 14 Sep 2002 04:34:35 +0000
• In-reply-to: <200209132340.g8DNeU313891@d...>
• References: <4.3.2.7.2.20020913163045.00c2ec80@m...> <200209132340.g8DNeU313891@d...>

Joe English <jenglish@f...> wrote:

|>> available at http://www.w3.org/TR/hlink/
| 
| Initial impression:  This looks OK. 

Being a first draft, it still needs a lot of work.

| It finally reinvents architectural forms in a way that's usable in XML.

I'm not sure this is true.  One problem is the dual nature of attributes
which carry URI "types", such as 'locator' and 'replacement'.  AFAIK,
locator="@href" is a perfectly valid relative URI reference.  There is
nothing in the draft to restrict the form of "real" URI references to
absolute paths or more, and I'm not sure that disallowing relative URI
references would be a good move.

The "high-tech solution" (I can just see it coming) would predictably be
[expletive deleted] XPointer in and finessing some interpretation of a fragment
identifier. 

The real problem is that a level of indirection is missing.  If the value
domain of an attribute is well-defined (in theory), trying to jigger
special cases or extended "magic" values is brittle design.  If the "type"
of the locator attribute is URIref, then let it be just that, URIref.
When you need to map information, ie to say "the value of the locator
attribute is actually the value of the href attribute", put this mapping
semantic, which is *also* a legitimate "value domain", in some attribute
dedicated to such a purpose.  This avoids ambiguity, misidentification,
magic value clashes, and all other problems that arise from not dealing
with names that are conceptually at the same level (here, attributes) in a
fashion where the equivalence of level is syntactically assured.  
 
| (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.)

So far, the discussion on TAG has been about how Steven's examples were
flawed (a misinterpretation of "embed").  That's one way to filibuster
against the real message!  (Which, I agree, was quite convincing.)

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

• Prev by Date: The Gnomes of the Web Speak
• Next by Date: Re: [Fwd: Re: The 11-pound solution (fwd)]
• 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