xml-dev - Re: various issues

[Peter@ursus.demon.co.uk (Peter Murray-Rust)]

You are very patient with me David, but light is beginning to dawn.  I think 
that we ahave been addressing different problems and I now partially understand
what you are getting at...


In message <199704111037.GAA00242@localhost> David Megginson writes:
> Peter Murray-Rust writes:
> 
>  > Thanks for the discussion - I am certainly finding it very
>  > interesting.  My impression is that implementing AFs at this stage
>  > is a lot of work and also that there is a considerable amount of
>  > simple tutorial material required (e.g. the SP material assumes you
>  > are familiar with the HyTime standard.)
> 
> That wasn't my impression -- James certainly makes passing reference
> to HyTime, but he does not seem to assume prior knowledge of the
> standard (I first learned about AFs from James's doc, without [at that
> time] any but a passing knowledge of HyTime).  That said, his doc is
> not meant (I think) as a beginners' tutorial, though it is the closest
> thing we have right now.

Understood and no criticism implied.  But terms are used on the assumption
that they are understood beforehand.  It's clear that we need a 
ReallySimpleGuide to this for people like me.

> 
>  > I'm not clear what the meta-DTD looks like, so here is a possible
>  > problem:
> 
> It usually looks exactly like a regular DTD, unless you use a couple
> of minor syntax extensions allowed (but not required) by the annex.
> You could use DocBook, HTML 32, or TEI-Lite (to give three examples)
> as meta-DTDs.
> 
>  > My DTD (CML) includes (say) HTML 3.2 which contains a SUB element.
>  > Now suppose I want to incorporate another DTD which does maths -
>  > let's call it MATH.dtd, and find that it has a namespace collision
>  > with SUB.  Do I create a meta-DTD which describes two separate AFs?
>  > If so, what does it look like (in very simple terms).
> 
> You do not include either DTD -- instead, you map some elements to
> elements in the HTML DTD, some elements to elements in the math DTD,
> some to neither, and some to both.  For example,
> 

What follows is the meta-DTD, right?  And the system knows it's
a meta-DTD because of the inclusion of one or more <?ArcBase PIs?

>   <?ArcBase html?> <?ArcBase math?>
> 
>   [notations and entities omitted]
> 
>   <!ELEMENT para ...> 
>   <!ATTLIST para
>     html      NAME    #FIXED "p">
> 
>   <!ELEMENT fraction ...> 
>   <!ATTLIST fraction
>     math      NAME    #FIXED "frac">
> 
>   <!ELEMENT sym ...> 
              ^^^     (I assume this is 'symbol'?)
>   <!ATTLIST symbol
>     html      NAME    #FIXED "sym" 
>     math      NAME    #FIXED "symbol">
> 

What this is doing is mapping elements in different DTDs to the same element
in your meta-DTD.  This implies that they are synonyms in some way.  Does it
assume that they have the same content model, attributes and that the elements
in the content model have (recursively) been mapped onto the DTD.  Or are you
essentially aliasing SYM in HTML to SYMBOL and SYMBOL in MATH to SYMBOL
but having to provide different content models and processing for each?


(This is a superset of my problem which was simply what
I did with the same GI in different DTDs.  Effectively I would want something 
like:
<!ELEMENT HTML-VAR ...>
<!ATTLIST HTML-VAR
    html NAME #FIXED "var">

<!ELEMENT CML-VAR ...>
<!ATTLIST CML-VAR
    cml NAME #FIXED "var">

and I would provide something separate for each one.

> You still have to declare every element in your own DTD, whether or
> not it is mapped to something in a meta-DTD.

This means your DTD is a superset of the other DTDs and your own elements?

> 
>  > > It would not be hard to implement data-attribute support in XML,
>  > > but the committee might not be thrilled with the idea -- it will
>  > > probably seem too much like creeping featurism.  I imagine that
>  > > they will probably end up using processing instructions instead
>  > > of data attributes.  I agree with Peter in preferring data
>  > > attributes.
>  >  Presumably one attraction of PIs is that the current parsers (and
>  > XML-LANG spec) won't have to be changed?
> 
> The disadvantage is that, since data attributes are naturally

I assume that the syntax you have written above is an example of
data-attributes??  If not, could you give an example :-)

> associated with a single notation, and notations are naturally
> associated with a single base architecture, it is easy to keep track
> of what goes with what.  Perhaps additional arguments to the <?ArcBase
> ...?> PI would be the best alternative.
> 
>  > I assume that it's easiest to build these systems if the two DTDs
>  > don't interact at all (i.e. represent completely separate pieces of
>  > information.)
> 
> Not necessarily: you will run into problems only if the overlapping
> structures are different; the names are not an issue.

I think I start to understand.  By 'structure' you mean the tree structure
of each DTD?  In which case AFs are a way of providing multiple views of the
same document?

> 
>  > [I liked the article by Steve Newcomb - although again it assumed
>  > some familiarity with HyTime in places.  It is clearly a vision
>  > that I would wish to evolve towards though again the mian problem
>  > is education.]
> 
> There is __no__ need to learn HyTime to understand Architectural
> Forms.  HyTime is simply one of many possible base architectures.

Good!  This Q+A is very useful for me.  I can understand why the WG decided
it was ambitious at present - if there were a minimal set of PIs or equivalent
I can see that this could be less hairy to implement.
> 
	P.

-- 
Peter Murray-Rust, domestic net connection
Virtual School of Molecular Sciences
http://www.vsms.nottingham.ac.uk/

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