Re: [xml-dev] ArchForns and LPDs

[Marcus Reichardt <u123724@gmail.com>]

Ah thanks Arjun for doing the effort to lookup the spec and
recapitulate from memory.

I know these arguments, but find them unconvincing:


1. Injecting LPDs

Not entirely sure but I guess you mean you can't just syntactically
inject an LPD into an arbitrary instance document since the document
prolog has to have a declaration for that LPD. In that case, entities
don't help either since you can't use parameter entity references
outside a declaration set (other than as part of markup declarations
in content eg marked sections) anyway. So this won't work

    <!DOCTYPE src [ ... ]>
    <!DOCTYPE intermediate [ ... ]>
    <!DOCTYPE target [ ... ]>
    %linkset-decls

to achieve something like:

    <!DOCTYPE src [ ... ]>
    <!DOCTYPE intermediate [ ... ]>
    <!DOCTYPE target [ ... ]>
    <!LINKTYPE lnk1 src intermediate [ ... ]>
    <!LINKTYPE lnk2 intermediate target [ ... ]>

(and any result DOCTYPEs have to be in the document prolog anyway,
since DOCTYPE #IMPLIED can only pickup a DTD for the base (primary)
DOCTYPE).

Now to work around that, you could organize you doc similar to the following

    <!DOCTYPE doc [
      <!ENTITY content SYSTEM "content.ent">
    ]>
    &content

(which I'm guessing you're suggesting). But even allowing creative use
of implied general entities to tell an SGML parser about additional
(architectural/Meta-) DTDs, you *still* need to sneak the ArchForms PI
into the document using parameter entities somehow. So the prospect of
defining a generic mapping facility using ArchForms without touching
source documents is just as hopeless as it is with LPDs, if that was
the goal.


2. Notations decls in LPDs

Citing from James Clark's SP reference
(<http://www.jclark.com/sp/archform.htm>) stated also in the context
of driving architectural processing from an LPD (specifically, to
inject an arch notation as an alternative to an archform PI) but
applying to LPD syntax in general:

> The architecture notation declaration and associated attribute definition list declaration are
> allowed in the LPD. Although the productions of ISO 8879 do not allow a notation declaration
> in a link type declaration subset, it is clearly the intent of the standard that they be allowed.

So it's not like the reference implementation is beyond bending the rules :)


3. Semantics of link rules

Indeed, SP has never implemented those rules, sticking to what's
specified in formal ISO 8879 clauses instead. The following document:

    <!doctype test [
    	<!element test - - (sub+)>
    	<!element sub - - (subsub+)>
    	<!element subsub - - (subsubsub+)>
    	<!element subsubsub - - (subsubsubsub+)>
    	<!element subsubsubsub - - (#pcdata)>
    ]>
    <!doctype out [
    	<!element out - - (osub+)>
    	<!element osub - - (osubsub+)>
    	<!element osubsub - - (osubsubsub+)>
    	<!element osubsubsub - - (osubsubsubsub+)>
    	<!element osubsubsubsub - - (#pcdata)>
    	<!attlist (out|osub|osubsub|osubsubsub|osubsubsubsub) attr cdata
"from-dtd-default">
    ]>
    <!linktype l test out [
    	<!link #initial test out sub #uselink l2 osub [
attr="from-initial" ] subsubsubsub osubsubsubsub [ attr="from-initial"
]>
    	<!link l2 subsub #uselink l3 osubsub [ attr="from-l2" ]>
    	<!link l3 subsubsub osubsubsub [ attr="from-l3" ]>
    ]>
    <test><sub><subsub><subsubsub><subsubsubsub>whatever</subsubsubsub></subsubsub></subsub></sub></test>

when processed using eg. "onsgmls -a l -t out.rast <the-file>" will
produce (into the out.rast file):

    [TEST
    #LINK-RULE
    #RESULT=OUT
    ATTR=
    !from-dtd-default!
    ]
    [SUB
    #LINK-RULE
    #RESULT=OSUB
    ATTR=
    !from-initial!
    ]
    [SUBSUB
    #LINK-RULE
    #RESULT=OSUBSUB
    ATTR=
    !from-l2!
    ]
    [SUBSUBSUB
    #LINK-RULE
    #RESULT=OSUBSUBSUB
    ATTR=
    !from-l3!
    ]
    [SUBSUBSUBSUB]
    |whatever|
    [/SUBSUBSUBSUB]
    [/SUBSUBSUB]
    [/SUBSUB]
    [/SUB]
    [/TEST]

Notably, osubsubsubsub isn't produced as result element, which it
would be by falling back to the #INITIAL rule (and neither does SP
produce the corresponding link attributes for analogous implicit
links), so I'm concluding that SP doesn't implement linktype fallback
to a parent linkset at all.

But I don't see the problem with this (in fact, I think it's
reasonable), since you could use regular parameter entities for link
rules, just as you'd use parameter entities to avoid redundancy in any
other markup declaration.

My guess is it's merely an accident and follows from the HyTime
editors desire to not, at all costs, introduce new constructs into
SGML itself and rather have HyTime layered cleanly as an SGML
application. Maybe it's also a matter of pushing changes through ISO
processes and reaching new consensus, I don't know; but in any case
would need addressing in a future revision of ISO 8879 ;)

On 7/25/21, Arjun Ray <arayq2@gmail.com> wrote:
>  On Sat, 24 Jul 2021 10:26:09 +0200, Marcus Reichardt
> <u123724@gmail.com> wrote:
>
> | (Now SGML also has LPDs, a type of declaration set available in
> | addition to DTDs, to basically do the same thing, and that can be even
> | pipelined OOTB; it's unclear to me why archforms didn't extend LPDs
> | but rather invented it's own IS10744 PI for basically the same thing
> | without adding power where it was needed, such as for dealing better
> | with attribute mappings or filtering).
>
> A tangled tale, and I'm not sure that, working from memory, I have all
> the details correct (as I wasn't there when the relevant decisions
> were made.)
>
> LPDs were defective in a number of ways, the most significant of which
> was that notation declarations were not - and still are not - allowed
> in them.  Another problem was that LPDs come between DTDs and instance
> data, so you have to split documents into separate DTD and text entity
> components to splice an LPD in between.  There is no easy way to just
> "layer" an LPD on top of a regular parse process.
>
> And, to top it off, the link process itself was mis-specified in the
> standard.  The SGML Handbook is a hindrance here, as it paints a false
> picture; or rather, paints a picture in line with "spirit" but not the
> "letter" of the standard.  Section 12.4 "Current Link Set" in the
> Handbook has this:
>
> : The principles for determining the current link set are similar to
> : those for determining the current short reference map (see 11.6.3).
> : Unlike short reference maps, however, where the current map is the
> : only one that is considered at any point in time, the current link
> : set is only the first to be searched for an applicable link rule.
> : If not found, the link set of the parent element is searched and so
> : on backward to the initial link set.
>
> That's the "spirit", or what was intended.  But the "letter" of the
> standard has _identical_ wording between 11.6.3 for short reference
> maps and 12.4 for link sets.  So, the hierarchical treatment was
> mandated to be the same - a serious blunder in the wording.  In the
> event, the treatment for short reference maps "won", probably by dint
> of greater applicability.
>
> Which made LINk unusable for architectural mappings (without serious
> redundancy.)
>
> So, a different mechanism altogether had to be invented to declare and
> use ArchForms.
>
> _______________________________________________________________________
>
> XML-DEV is a publicly archived, unmoderated list hosted by OASIS
> to support XML implementation and development. To minimize
> spam in the archives, you must subscribe before posting.
>
> [Un]Subscribe/change address: http://www.oasis-open.org/mlmanage/
> Or unsubscribe: xml-dev-unsubscribe@lists.xml.org
> subscribe: xml-dev-subscribe@lists.xml.org
> List archive: http://lists.xml.org/archives/xml-dev/
> List Guidelines: http://www.oasis-open.org/maillists/guidelines.php
>
>