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

 


Help: OASIS Mailing Lists Help | MarkMail Help

 


 

   Re: AFs and the DPH

[ Lists Home | Date Index | Thread Index ]
  • From: Paul Prescod <papresco@technologist.com>
  • To: xml-dev@ic.ac.uk
  • Date: 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.
 
> 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?

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? 

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.

 Paul Prescod


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)





 

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

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