ASPN ActiveState Programmer Network
ActiveState
/ Home / Perl / PHP / Python / Tcl / XSLT /
/ Safari / My ASPN /
Cookbooks | Documentation | Mailing Lists | Modules | News Feeds | Products | User Groups


Recent Messages
List Archives
About the List
List Leaders
Subscription Options

View Subscriptions
Help

View by Topic
ActiveState
.NET Framework
Open Source
Perl
PHP
Python
Tcl
Web Services
XML & XSLT

View by Category
Database
General
SOAP
System Administration
Tools
User Interfaces
Web Programming
XML Programming


MyASPN >> Mail Archive >> xml-dev
xml-dev
[xml-dev] Renamer-att (was: Can XLink be fixed?)
by Arjun Ray other posts by this author
Aug 24 2002 10:17PM messages near this date
RE: [xml-dev] Re: Can XLink be fixed? | Re: [xml-dev] Renamer-att (was: Can XLink be fixed?)
"Keith W. Boone" <keith@[...].org>  wrote:

[on using an extension on XPointer]

| So now, you could define the xlink attributes on img to be fixed, as
| follows:
| 
| <!ELEMENT img EMPTY> 
| <!ATTLIST img
| 	xlink:type	(simple)	#FIXED 	'simple'
| 	xlink:href	CDATA		#FIXED	'#eval(here()/../@src)'
| 		:
| > 
| [...]
| Now arguably, eval() is overkill to solve this problem. 

Very much, not to mention building in dependency on yet another spec, with
all its own complexities and support requirements.  This 

Also, this does not remove the need for colonified names in declaration
subsets and the associated jiggery-pokery with PEs and whatnot to make
that "work".  That is, this proposal says nothing constructive about the
provenance of the "xlink:" prefix in all those attribute names, which is
after all how the connection to the "namespace" is established.

| Since most use would simply be in the form '#eval(here()/../@src)', you 
| might define a scheme named link(attr), whose argument is the name of an 
| attribute.  

To put it simply, a scheme that maps one attribute to another.  Since it's
only about mapping anyway (and *just* mapping), why can't the mechanism be
kept simple?  Rather than add something to another spec and pull that spec
in, why not develop something suited to the task at hand?  (Do we really
need to order a customised set of ginsu knives just to butter our toast?) 

The ArcNamrA or renamer-att facility of AFs names an attribute the content
of which specifies the renaming map.  The attribute value is a whitespace
separated list of (paired) tokens, either an ordinary name or a reserved
name ("#GI", "#ARCCONT" and "#CONTENT") corresponding to things which are
not named by an attribute.

A scheme which requires no new understanding other than the notion of a
list of paired tokens could work as follows:

1.  Define a special attribute in the reserved space of names which begin
with 'xml'.  For concreteness, I nominate 'xmlmap'.  The value of an
xmlmap attribute will be a list of paired names, the first of each pair
being the name of a "scheme" or "namespace" or "architecture" or whatever,
and the second being the name of a mapping attribute.

2.  The value of any such mapping attribute will be a list of paired
tokens, associating a name in the "whatever" with an attribute of the
current element.  

3.  The tokens in the mapping attribute can also take two special values
besides names of attributes, corresponding to the two "unnamed attributes"
of an element: the generic identifier ("#GI") and the syntactic text data
content ("#CONTENT").

Thusly:

 <!ELEMENT  img       EMPTY
            > 
 <!ATTLIST  img
            xmlmap    NMTOKENS   #FIXED  "xlink foomap"
            foomap    CDATA      #FIXED  "type type href href"
            type      NAME       #FIXED  "simple"
            href      CDATA      #REQUIRED
            -- etc. --
            > 

Note that this will work with instance markup too, not just an ATTLIST
declaration.
     
All that remains is to fix the provenance of the first name in each pair
of the xmlmap attribute value.  Namespace afficionados can concoct their
own namespace declaration syntax (probably a PI), while another approach
might get by with simply a notation declaration.

No need for PEs, either!
 

-----------------------------------------------------------------
The xml-dev list is sponsored by XML.org <http://www.xml.org> , an
initiative of OASIS <http://www.oasis-open.org> 

The list archives are at http://lists.xml.org/archives/xml-dev/

To subscribe or unsubscribe from this list use the subscription
manager: <http://lists.xml.org/ob/adm.pl> 
Thread:

Rick Jelliffe
Henry S. Thompson
Norman Walsh
Norman Walsh
Paul Prescod
Simon St.Laurent
Norman Walsh
Simon St.Laurent
Robin Berjon
=?iso-8859-1?Q?Bill_de_h=D3ra?=
Simon St.Laurent
Paul Prescod
Simon St.Laurent
Robin Berjon
Simon St.Laurent
Simon St.Laurent
Norman Walsh
Simon St.Laurent
Norman Walsh
Simon St.Laurent
Simon St.Laurent
Simon St.Laurent
J. David Eisenberg
Norman Walsh
J. David Eisenberg
Robin Berjon
Norman Walsh
Simon St.Laurent
Norman Walsh
Simon St.Laurent
Simon St.Laurent
Simon St.Laurent
Simon St.Laurent
Shane McCarron
Simon St.Laurent
Joe English
Norman Walsh
Simon St.Laurent
Keith W. Boone
Arjun Ray
Arjun Ray
Rick Jelliffe
Simon St.Laurent
Simon St.Laurent
Tim Bray
Simon St.Laurent
Tim Bray
Simon St.Laurent
Elliotte Rusty Harold
Simon St.Laurent
Lars Marius Garshol
Bob DuCharme
Elliotte Rusty Harold
Didier PH Martin
Elliotte Rusty Harold
Simon St.Laurent
Elliotte Rusty Harold
Norman Walsh
Tim Bray
Simon St.Laurent
Tim Bray
Simon St.Laurent
Simon St.Laurent
Simon St.Laurent
Ann Navarro
Simon St.Laurent
Elliotte Rusty Harold
Simon St.Laurent
Simon St.Laurent
Elliotte Rusty Harold
Simon St.Laurent
John Cowan
Rick Jelliffe
Simon St.Laurent
John Cowan
Simon St.Laurent
John Cowan
Simon St.Laurent
Mike Champion
Didier PH Martin
John Cowan
Mike Champion
Simon St.Laurent
Norman Walsh
Tim Bray
Simon St.Laurent
Rick Jelliffe
Norman Walsh
Masayasu Ishikawa
John Cowan
Jeff Rafter

Privacy Policy | Email Opt-out | Feedback | Syndication
© ActiveState Software Inc. All rights reserved