xml-dev - Re: AFs and the DPH

[Peter Newcomb <peter@techno.com>]

[Paul Prescod <papresco@technologist.com> on Fri, 03 Oct 1997 13:45:43 -0400]
> W. Eliot Kimber wrote:
> ...
>> NOTE: If the architectures meta-DTD is identical to what would be the
>> document's DTD if it had one (for documents without DTDs), then all
>> mapping is automatic and there's no need for additional attributes in
>> the instance.  In other words, given a document with an explicit DTD,
>> you can remove the DTD, make it an architectural meta-DTD, and get the
>> same processing result.  This is why I think architectures are key to
>> the success of XML: it lets you eat the cake of DTD-less documents and
>> still have it (because the architecture processing gives you all the
>> validation and processing you need, but only when you want it and not
>> when you don't).

> I don't understand this. How does turning the DTD into a "architectural
> DTD"* help anything? Just as in ordinary XML you can process the
> (perhaps architectural) DTD if you want to validate, or skip if you
> don't want to.

I think that what Eliot is referring to here is the ability to
hard-code support for an architecture into a processor and then still
be able to use it on documents that might inherit also from other
architectures, but that do not have DTDs.  Thus you can re-use
software that expects a certain DTD on documents that do not actually
have DTDs.  Eliot?

>> Any abstract API (like Xapi-J) can be usefully enhanced to make getting
>> architecture-specific properties easier.  For example, in the work I've
>> done with ADEPT*Editor, I created a set of functions to resolve
>> architectural mappings--these functions could easiliy be provided by
>> ADEPT out of the box.  

> Do your functions handle the mapping of attribute nodes to content,
> content nodes to attributes, minimization and the other neat
> transformational features of the AFDR? Do you think that the full suite
> of transformations is appropriate for XML, or merely element to element
> mappings? In my own thinking I have found it hard to figure out how one
> would efficiently implement those without having an entire second grove
> in memory. Let's say you *did* have both groves available. Then you
> could do a query in the architectural grove for elements that do not
> really correspond to any particular element in the source grove. How
> would you do that query *without* having both groves available? Is the
> only reasonable way to implement archforms to double (or triple, or
> quadruple, or....) the amount of memory taken up by groves in memory?

As far as I know, it's not possible to have an architectural element
without a client (source) element.

The attribute and content remapping facilities are probably critical
to good architecture and document design. The minimization features
are likely to be useful, but are not necessary. What are the other
"neat transformational features" you're talking about?

As far as architectural groves requiring much more memory than the
original grove is concerned, if your grove implementation is literal
(i.e., each node in a grove is its own object), then of course it's
true.  But if you implement groves that way, you're already incurring
a huge avoidable overhead even for a single SGML grove.  Remember that
a grove needn't actually be implemented as a grove; all that matters
is that the interface to the data, however it is stored, looks like a
grove.  Thus, while there is likely to be some overhead required for
efficient architectural grove implementations, it should be comparable
or even less than the overhead incurred by object oriented systems in
order to provide efficient type-querying and method-lookup for
objects.

> Also it seems to me that in architectural forms you can *either* get a
> single architectural stream, as is the case in the output of Jade, or
> you can get multiple fully constructed groves (as in GroveMinder), but I
> wonder if it is possible to do stream-based architectural processing of
> multiple groves at once? In other words is there a way to build
> something like an ESIS that provides multiple groves at once and makes
> links between them? Could you comment on what this stream would look
> like? I think that it is admirable that archforms work in these two
> different modes, but I might like to take advantage of the best features
> of both modes at once -- access to all architectural "views" and
> stream-based processing. Is this feasible? 

Sure... I think what this amounts to is an event interface where an
element object passed as an element event, for example, includes the
entire architectural element tree built from that element.  This
probably could be done with some not-too-extensive modifications to
SP.

> I think it comes back to my earlier question about emulating multiple
> groves without building them. This seems feasible to me in the simple
> case, but my head gets muddled when I start thinking about minimization
> and content/attribute remapping.

You have to build them, but you only have to build them when they're
asked for.  And then you only have to build the specific parts that
are asked for (i.e., from specific client elements).  (In SGML, this
can get a little tricky, however, when you take into account #CURRENT
attributes and suchlike.  The XML case should be much simpler.)

-peter

--
Peter Newcomb                           TechnoTeacher, Inc.
peter@petes-house.rochester.ny.us       peter@techno.com
http://www.petes-house.rochester.ny.us  http://www.techno.com

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)