Architectures capability question - attribute values to element G I?

[Steven R. Newcomb]

[Steve Harris:]

> Is it possible to use Architectures to map an attribute value to an
> element GI in the target architecture (that is, to 'dynamically
> specify' the architectural form)? This desire is in reverse to the
> common example usage of the 'renamer-att' architecture support
> attribute. I have seen this idea kicked around in various
> discussions, but cannot find any documentation or examples to back
> up the claim that it's possible.  The desired transformation would
> be from

> <!-- original document instance fragment -->
> <thing type="foo">bar</thing>
> <thing type="baz">gorp</thing>
> 
>   to
> 
> <!-- fragment after architectural processing -->
> <foo>bar</foo>
> <baz>gorp</baz>
> 
> Is this really a job for something like DSSSL or XSL? I'd like to find
> the limits of what Architectures can do. Please advise.

This example happens to be an especially natural case for the use of
an inheritable architecture.  No renaming attribute is required.  Let
me rename your "type" attribute to "orlando", and provide an "orlando
architecture meta-DTD" to make things clearer.

The orlando architecture (a meta-DTD):

<!ELEMENT orlandoDoc ( foo | baz)* >
<!ELEMENT foo ( #PCDATA) >
<!ELEMENT baz ( #PCDATA) >


<!-- document instance fragment: -->
<!-- (The orlando attribute gives the name of the architectural form 
     in the orlando architecture.) -->

<thing orlando="foo">bar</thing>
<thing orlando="baz">gorp</thing>


<!-- the "orlando" architecture's view of the same
     fragment, as, e.g., SP would report it: -->

<foo>bar</foo>
<baz>gorp</baz>
 

The value of the orlando attribute is, in effect, "the element type
name for orlando purposes".  This is the most fundamental thing to
know about how inheritable architectures work.

It occurs to me, on account of your use of the phrase "dynamically
specify", that maybe you're asking something more subtle, which I
would rephrase as follows:

  "Does the value of the architectural form name attribute have to be
  #FIXED in the DTD?"

The answer is "No."  There doesn't even have to be a DTD.  If you can
make it be #FIXED in the DTD, or at least default it in the DTD, that
can save a lot of markup from having to be specified in the instance,
because you won't have to say, e.g. "orlando=foo" in every <thing>
tag.  Even if there is a DTD, there is no requirement that the DTD's
GIs ("generic identifiers" or "element type names") correspond
consistently with the GIs of any of the meta-DTDs that are being
inherited.  So, it's perfectly OK for a particular <thing> element to
be, in orlando terms, a <foo>, and, even in the same document, for
another <thing> to be a <baz> in orlando terms.  (It may seem a bit
odd, but it does happen.  In fact, there's one place in the Topic Maps
architecture (which is about to be an ISO standard, BTW) where it
happens: a <topic> architectural form in the Topic Maps architecture
is sometimes a <HyBrid> and other times a <varlink> in the HyTime
architecture.)

-Steve

--
Steven R. Newcomb, President, TechnoTeacher, Inc.
srn at techno.com  http://www.techno.com  ftp.techno.com

voice: +1 972 231 4098 (at ISOGEN: +1 214 953 0004 x137)
fax    +1 972 994 0087 (at ISOGEN: +1 214 953 3152)

3615 Tanner Lane
Richardson, Texas 75082-2618 USA

xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev at ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1
To (un)subscribe, mailto:majordomo at ic.ac.uk the following message;
(un)subscribe xml-dev
To subscribe to the digests, mailto:majordomo at ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa at ic.ac.uk)