Using HyTime Arcform stuff (was Re: Ephemeral XML?)

>A formalism for declaring a document's derivation from an architecture or
>architectures is defined in the forthcoming HyTime TC (largely as
>documented for the architecture processing support in the latest releases
>of SP).  Unfortunately, the full form of these mechanisms depend on the use
>of data attributes (<!ATTLIST #NOTATION archname ...>), which means that
>XML documents cannot use the full form unless we add notation attributes to
>XML.

A warning before I start -- this was one of the things I wanted removed
from the HyTime TC. I don't think that HyTime has provided a base of
experience sufficient to standardize on a AF definition mechanism. Such a
mechanism should go throught the full ISO process as part of the SGML
revision, and not the abbreviated time-scale, review thoroughness, and
audience of the TC. Another difference would be that a good solution should
probably eventuate in new DTD declarations (and not PI hacks).

   That said, we will probably have to use something like this, anyway, as
we don't have any other syntactic leeway, and have decided to stick with
the notion of being a strict subset of SGML.

>However, the minimal part of the declaration simply uses a processing
>instruction to indicate which architectures are in use, e.g.:
>
><!DOCTYPE MyDoc [
> <?ArcBase XML-Link MyArc InfoMaster>
>]>
>
>Where the name "ArcBase" is effectively normative as XML doesn't allow SGML
>declarations, which is where you would change the name of the PI (don't you
>love indirection?).

At least this is not true: we can use <?XML-arch -XML-link>

We can simply specify the "conversion declaration" for links, the same as
we have specified a declaration for XML itself. This is one place where we
are not constrained.

>A full architecture processor then expects to see notation declarations
>corresponding to the architectures named (e.g., <!NOTATION MyArc PUBLIC
>"...">)
>with notation attributes defining the document-specific values for the
>architecture control attributes.

well, we are syntactically out of luck here. If we need any of these
options, we can define equaivalent mechanisms to invike them. We probably
won't need them.

>The architecture control attributes are needed to do renaming, specify
>options used, and so on.  However, since these attributes can all have
>default values, you could always derive an XML-specific version of your
>architecture that set the default values to something appropriate for XML
>use, following the XML philosophy that no options are good options.  Thus
>the notation attribute declarations would be superfluous because the
>architecture engine for each such architecture would know what its base
>default values are because they would be built in.  Thus, I could have:
>
><!DOCTYPE MyDoc [
> <?ArcBase XML-Link XML-MyArc XML-InfoMaster>
> <!NOTATION XML-Link PUBLIC "-//W3C::SGML ERB//NOTATION XML Link
>Architecture//EN" >
> <!NOTATION XML-MyArc PUBLIC "-//ME//NOTATION My Architecture, XML
>Profile//EN" >
> <!NOTATION XML-InfoMaster PUBLIC "+//ISBN 0-189773::IBM//NOTATION
>InfoMaster Architecture, XML Profile//EN" >
>
>]>
>
>It would conform to the ISO/IEC 10744 requirements and fit within the XML
>constraints.  The notation declarations could be considered superfluous in
>this case as the PI is sufficient to identify the architectures as long as
>the names used are normative.  In the general case, you can use whatever
>name you want because the architecture is actually identified by the
>external ID of the notation you declare.  However, we tend to expect the
>notation names to be used consistently.  Or, you could consider the names
>in the ArcBase PI to imply notation declarations with omitted system
>identifiers if no notation declaration is present, at which point things
>like catalog lookup come into play and you could put the name-to-public ID
>mapping in an external catalog if necessary (which it's probably not 99.99%
>of the time).

I strongly urge that we abandon any attempt to include these additional
markup bytes in XML linking. I'm not sure that we need notations at all, we
simply need a way for XML to declare what AFs are in use. If we decide to
allow _user defined_ AFs we might need notations.

In any case, rigamarole declarations like the above should not be required
for XML linking: the use of the XML-linking architecture can imply _all_
the declarations required by HyTime. In other words, given the lack of
legacy data ans legacy processors for HyTime (as amended by the TC) I think
that that level of compatibility is of minimal importance. Certainly, we
fail the stoopid test if we tell our users that they have to type in
anything like that to enable linking.

I'm worried that they will be antsy at a declaration like
<?XML arch xml-linking xml-forms>
which will be required by nearly every document.

I don't think we can sell too many lines of magic startup incantation, when
we're competing with no lines of magic incantation to get going with HTML.

  -- David

I am not a number. I am an undefined character.
_________________________________________
David Durand              dgd@cs.bu.edu  \  david@dynamicDiagrams.com
Boston University Computer Science        \  Sr. Analyst
http://www.cs.bu.edu/students/grads/dgd/   \  Dynamic Diagrams
--------------------------------------------\  http://dynamicDiagrams.com/
MAPA: mapping for the WWW                    \__________________________

Received on Tuesday, 14 January 1997 00:23:52 UTC