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 ]

Joe English <jenglish@flightlab.com> 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
sucking 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.)





 

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

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