xml-dev - Re: AFs and the DPH

[Peter Murray-Rust <peter@ursus.demon.co.uk>]

Many thanks to all who have contributed - please keep doing so.

I am gradually attaining enlightenment. [I think unless you have actually
practised AFs it's quite difficult for some people to pick them from the
abstract description.] The benefit of doing it here is that the
explanations are archived :-)

At 09:09 02/10/97 +0100, W. Eliot Kimber wrote:
>Peter Murray-Rust wrote:
>
>> May I reduce my ignorance further by asking some simple questions:
>>         - must a DTD (or at least an ATTLIST) always be provided with
the document
>> instance?
>
>Only if you want to avoid putting the mapping attributes in start tags
>(moral equivalent of qualifying names ala colonization) or want to use
>element types that are different from the architectural names
>(remembering that by default, if an element has the same GI as a form in
>the active architecture, it is mapped to it automatically).

This was also made very clear in David Megginson's proposal - thanks.

>
[...]
>
>>         - if so, how is this information going to be transmitted to the
AF-aware
>> processor. Will Xapi-J do this?

What I meant was - 'If a document + all associated components (DTDs, PIs,
etc.) has been processed by an Xapi=-J compliant tool, will the information
recoverable from that be enough to show that AF-processing is required and
how to do it?' Taking DavidM's syntax (which is XML compatible and where
the AF-ness is indicated by PIs, it seems the answer is 'yes' :-)

>
>I'm not sure what you mean by 'this information'.  Do you mean the
>mapping itself? If the attributes are declared or specified, they're
>simply part of the properties of the elements and any AF-aware processor
>can examine the attributes to look to see if there are any it
>recognizes.
^^^^^^^^^^^
This implies that the AF-processor is either hardcoded to a particular AF
(I suppose XML-LINK might fall into this category, but I'd feel unhappy for
any more specific hardcoding), or a general AF-process is fed a list of the
attributes it needs to look out for.
  
>Automatic mapping is slightly more work, because you have
>to know what form you are looking for (either because you have
>hard-coded it into your processing (e.g., if (gi == 'some-form') {}) or
>because you are also looking at the meta-DTD).  In the simple case, your
>AF-aware processor is expecting certain element forms and attributes and
>simply looks for them, rather than trying to do generalized architecture
>processing.  This is funtionally equivalent to having a processor tied
>to a particular DTD except that you look first for architectural
>attributes and *then* at GIs, rather than starting with GIs.

How does DavidM's proposal fit into this where - presumably - you indicate
what you are looking for via PIs? Is this also the way that SP works? If
so, could there be an agreed set of PIs?


>
>Any abstract API (like Xapi-J) can be usefully enhanced to make getting
>architecture-specific properties easier.  For example, in the work I've

Is this something worth doing?

[...]
>
>With these functions, it's pretty easy to do architecture-aware
>processing just as
>you do DTD-aware processing, e.g.:
>
>$archform = &ArchFormOf($current_node, 'XML-LINK');
>if ($archform == 'SIMPLE') {
>   print STDERR "Found a simple link element\n";
>} elsif ($archform == 'EXTENDED') {
>   print STDERR "Found an extended link element\n";

I'm not quite clear how this differs from simply processing attribute
values (which is what I do at present).

[...]

P.

	
>
Peter Murray-Rust, Director Virtual School of Molecular Sciences, domestic
net connection
VSMS http://www.nottingham.ac.uk/vsms, Virtual Hyperglossary
http://www.venus.co.uk/vhg

xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/
To (un)subscribe, mailto:majordomo@ic.ac.uk the following message;
(un)subscribe xml-dev
To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)