xml-dev - Re: XML-Data: advantages over DTD syntax?

[Derek Denny-Brown <ddb@criinc.com>]

At 02:14 PM 11/29/97 -0600, W. Eliot Kimber wrote:
>At 11:46 AM 9/29/97 -0700, Derek Denny-Brown wrote:
>I'm not sure I follow you.  If you have an architecture-aware search
>engine, then you should be able to do a query of the form "find all
>elements derived from the form 'animal'", which will include both 'animal'
>elements and 'duck' elements.  How is this not 3?  Or do I misunderstand
>Henry's requirement?

This requires a AF aware search engine.  In addition, all current AF
systems can only view the instance as either the source or the AF.  If the
search engine reports where it found the match, it would report it relative
to the AF, not the source document.  As I implied in my original post:
>> although AF could provide a solution if used in
>> an envirnment which supports simultanious view 
>> of the source and AF instances with links between
>> the two.
a number of things start to change when you add an environment wheren you
can easily map back and forth between the two views.

>Again, I don't follow you.  Either you really have a completely new DTD and
>you have to define the processing for it completely or you have a DTD
>derived from an architecture *and* you have architecture-aware processors
>that let you apply the architeture-specific processing to your new
>documents, leaving only the new stuff to be defined.  How do architectures
>not do this? How would the XML-Data proposal do this any better? In both
>cases, it's a function of the processing code both providing the methods
>for the base classes and the processing system understanding the derivation
>hierarchy.

I want to build on tools which assume you are using an existing DTD, say a
custom editor environment. (note: this is not based on a real
implementation, but rather a mental exercise)  From the point of view of
that tool I either am using a new DTD (since I can not have a nice PUBLIC
reference to the "standard" DTD, and the DTD is different in any case,
because I added elements to some content models) or I only give it the AF
and I have lost my value added elements.  I am talking about today and
tomorrow, not next year.  Next year there may be tools which allow better
use of AFs.  I am not in a position where I have enough information to
really know what vendors plan to release next year.  I am in a situation
where if it can not be done today, I can not use it, since my deadlines are
too tight to wait on future releases for most of the software. (note: if
you want grey hair at an early age, this is an excelent recipy.  managers
who do not want their staff to have grey hair should either take note or
buy lots of hair dye...)

I have never said that XML-Data provides anything better, since I do not
know enough about it to even compare it to AFs, which I do have a
reasonable understanding of, I think.

>You can also use the trick of defining the architecture such that its
>declarations (and in particular, the parameter entities used to configure
>and modularize it) can be also used to create declarations for documents
>derived from the architecture.  In essessence you combine architectural
>derivation with the sort of clever modularization typified by the TEI and
>Docbook declaration sets.

This requires that the original be well designed.  A common request, which
is often ignored ;}


>Your comments suggest that you are confusing *parsing* with *processing*.
(Hopefully) no more than current tools force me to  co-relate them.  They
should be seperate, but are more often than not, virtually synonymous.
Groves are setting the stage for a day when parsing and processing are
seperated.  At times I dream of that day, interspersed with my nightmares
imposed by current tools and requirements...

>Parsing is not an issue, because the document is either valid to its DTD or
>it isn't, and is either valid with respect the governing schema or isn't.
>Whether or not the document is valid doesn't affect how it is *processed*
>after parsing, which is purely a function of methods applied to types, not
>parsing, and is entirely independent of how the type information got
>associated with the data (whether by the architecture syntax or the
>interpretation of some XML-Data document).

The problem is that a number of tools/environment define a document's
model/style/environment by the DTD.  If I have a special setup for editing
DocBook documents, that setup needs to make some assumptions on your
instance.  It does not work when I hand it an instance which violate those
assumtions (because it is conformant to a DTD which uses DocBook as a base
architecture, rather than actually being conformant to the DocBook DTD).
If I have access to the source, I could go in and tweak it, but I would
have to do this either specifically for the new DTD or spend the time to
make the environment work with anything which remotely resembles
DocBook....more work than I want.

>>This is exactly what OO Inheritance allows a programmer to do.  You need
>>an extra attribute? Easy!  With AF's I either see the document as the new
>>DTD or I can not see the attribute... value lost either way.
>
>This is only true if you define your processing in terms of architectural
>instances derived from documents, but clearly, that is not the way
>architectures are intended to be used in the general case.  The
>architecture provides part of the processing and an architecture-aware
>processor must be able to associate architecture-specific processing with a
>document, but it's not an all-or-nothing proposition.  I must always be
>aware of the document's architectural nature as well as its base nature
>unless the only processing I care about at the moment is that defined by
>the architecture.

To an extent what I am asking for is an environment where I could build
tools using a traditional OO Inheritence model applied to the SGML AF
model.  A DSSSL Style sheet where I would only have to define rules for new
elements (or changed elements).

>This is why confusing architectures with object-oriented programming
>approaches is so dangerous: they are not the same thing and thinking that
>they are leads to erroneous conclusions and unrealistic expectations (such
>as that content models can be somehow inherited in any but the most trivial
>ways).

I agree that AFs shoud definitely no be equated with OO programming.  I do
see two things which any attempt to equate them does bring out.

1) DTD extension mechanisms which provide for simple type inheritence would
be very usefull.  AFs provide a limited solution, which presents new
difficulties.  This is a problem with SGML.  AFs are an excellent
workaround which stays within the system, and deserve considerable credit
for that.  My reel frustration is with SGML and the limits it imposes, not
AFs.

2) Tools which allow OOP inheritence style defaulting behaviour for
processing of elements based on element-type, architectural type.. AFs may
not map to OOP but they make OOP based processing tools easier...

>Note too that when you have DTD-less documents, problems of DTD syntax
>munging go away because you don't have any DTD syntax to mung.  Any munging
>is managed by the creators of derived schemas.  This is one of the beauties
>of XML--it frees us from the need to conflat schema definition with the
>definition of the parsing rules for document instances.  

But this puts added burden on the tools since all bets are off as to what
the structure looks like.  AF at least provide a set mechanism for mapping
to a known structure.

-derek

     Derek E. Denny-Brown II      ||   ddb@criinc.com
     "Reality is that which,      ||   Seattle, WA USA
  when you stop believing in it,  ||  WWW/SGML/HyTime/XML
 doesn't go away."  -- P. K. Dick || Java/Perl/Scheme/C/C++

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)