Re: DTD Fragments and XML

Excuse my posting agin almost immediately :-)

In message <199705031958.UAA12146@curia.ucc.ie> Peter Flynn writes:
[...]
> 
> Incidentally, I have assumed that WF documents, because they have no
> DTD are, strictly speaking, not SGML. And you cannot use attributes
                                                ^^^^^^^^^^^^^^^^^^^^^
Help! I have no problem in doing this all the time :-) - see previous posting.
If I write:
<!ELEMENT FOO EMPTY>
<!ATTLIST FOO BAR CDATA #IMPLIED>

and create a doc:
<FOO BAR="BAZ"/>

I can't see that the *DTD* has given me much additional information.  And
if I create a document:
<OBJECT HREF="http://expasy.hcuge.ch/sprot/sprot-bin?INS_HUMAN"
    BEHAVIOR="http://www.nottingham.ac.uk/vsms/java/jumbo/SEQNode.class"/>

the semantics are precisely resolvable within my community and lead to
automagical display... where the DTD doesn't help at all.

> in WF documents, ever? (I may have missed something here: I need to have
> this right for the FAQ).
> 
[...]
> 
> I'm guessing but I don't think it is impossible to make XML versions
> of popular and useful DTDs that are modular and easily modifiable.
> But it would be way easier with some tools: in making HTML Pro it was 
> easier because I used Near&Far to cut and paste chunks of many DTDs,
> then tidy them up in the exported ASCII file. But this is not user-level
> manipulability.

Conventional DTDs such as 12083 seem to include constructs for both document
form and sub-lement content.  For example, an <ABSTRACT> is a piece of
text which plays a special role, but it's still text.  I use exactly the 
same code to render an ABSTRACT as a PREFACE. I would have thought
that many common DTDs could be reduced to quite a small number of 
information components, most derived (inherited) from some generic
TEXT object.

In similar vein, TecML can quite easily manage stock prices, football
scores, etc. just as easily as quantum chemistry.  Re-usable information
components for structured and annotated numeric data.

> 
> >I don't think that we can make it easy to combine DTDs without changing
> >SGML. But maybe we can figure out a way to declare a namespace for
> >elements: to "import" element names in a standard way. You wouldn't be
> >able to validate the document but at least it would be clear what the
> >elements MEAN.
> 
> This borders on AF for XML, and I don't see that in the workplan. My
> $0.02 is that we are going to NEED, really need, a simple way to convey
> to an XML browser "Hi, this is my DTD (or WF instance) and on this
> occasion I have used <FOO> for a table, <BAR> for rows, and <BLORT>
> for cells. Please carry on". Right now we can only interoperate at
> the stylesheet level, and I don't see AFs in stylesheets (yet?)

We can also interoperate at the BEHAVIOR level and (in essence) JUMBO
already does this.  If elements can be constructed with METHODS, and
those methods can accept parameters, then we have a very flexible system.
For example, TecML deals with graphs by using the XLIST container to
hold two ARRAY, something like:

<XLIST CONTENT="GRAPH" DISPLAY="BAR">
  <ARRAY TYPE="FLOAT">1 5 7 3 8</ARRAY>
  <ARRAY TYPE="FLOAT"> 3.1 2.3 7.4 3.1 9.2</ARRAY>
</XLIST>

This includes some of my learning experience and so I'd perhaps decouple
DISPLAY (i.e. STYLE) from the data now - when there is an agreed mechanism.
And XLIST can easily have XML-LINK attributes of such as:
BEHAVIOR="http://gnuplot.or.excel.or.sas/PLOT.class"
to allow for different ways of treating the dsiplay.

	P.

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

Received on Saturday, 3 May 1997 16:53:01 UTC