Cart
|
[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] Re: XHTML 2.0 and the death of XLink and XPointer?
At 09:18 AM 8/12/2002 -0600, Uche Ogbuji wrote:
>But was the use of namespaces really their biggest problem? Why? Because
>the
>documents would have to add another namespace (silly objection, that)?
>Because they wanted all elements of their vocabulary in one seamless
>anmespace? (I can't think of any technical reason for needing this).
That seemed to pretty much be it, but I'd be happy to be
corrected. Issues of backwards compatibility were cited, in that they
wanted existing Web folks to adopt their standard. Seeing as XHTML 1.0 has
largely been ignored by the community, I can't see how that objection
stands...backwards compatibility ceases to be an issue, in my opinion, if
nobody adopts the new standard. That's when it's time to go back and fix
all the stuff that was broken in the first place, or is no longer compliant
with newer technology.
And, as you've pointed out, XHTML uses namespaces. So, it seems
like the namespace issue is now a non-issue, at least from my perspective.
I'd be delighted to hear from XHTML folks on this, especially as my wee
little brain issues forth steam trying to write up a technical solution to
the outstanding issues. It'd be a relief to drop the namespace issue from
the list of problems I'm looking at.
>Anyway, where is the XLink issues list? I can only find the pointers to the
>comments group and archives in the REC itself (forgive me: I don't have the
>time to comb through all of these). Googling for "XLink issues list" and
>even
>"XLink issues" bears no quick fruit.
It's at:
http://www.w3.org/XML/2000/10/xlink-CR-comments.html
And the last call comments are at:
http://www.w3.org/2000/06/xlink-comments.html
I believe these are public documents, but I'm not sure.
>This is one of the things that do annoy me about XLink. I wish it had not
>attempted to add constructs that even hint at processor behavior. I think
>Paul Prescod and others fought against this much earlier on.
And I'd rather it did the opposite, specifying behaviours with
links to the appropriate specifications. Something like: "OnRequestNew does
<blurb/> and is derived from XHTML 1.1, found at <reference/>."
Anything short of that seems to open up a big, nasty bunch of
interoperability issues.
>I don't have a problem with there being a suggested processing model. I just
>don't think this belongs in the XLink spec. There could be an XLink
>processing spec, which adds actuate="" (and the additional constructs that
>are
>needed for complete specification of processing), and users of XLink could
>use
>its suggested processing model where it makes sense, but not as core XLink.
Well, I do disagree with that. I think a processing model is
required, especially if we're to expect CSS and XSLFOs that deal with all
the various link behaviours and such. You haven't presented any arguments
against this position from a technical viewpoint; I'd be interested in
hearing them.
--->Ben
|
PURCHASE STYLUS STUDIO ONLINE TODAY!Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced! 
Download The World's Best XML IDE!Accelerate XML development with our award-winning XML IDE - Download a free trial today! Subscribe in XML format
|
|||||||||
