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

 


Help: OASIS Mailing Lists Help | MarkMail Help

 


 

   Renamer-att (was: Can XLink be fixed?)

[ Lists Home | Date Index | Thread Index ]

"Keith W. Boone" <keith@woc.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!
 




 

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

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