<?XDEV?> and BEHAVIOR: a meta-proposal and a proposal

Peter Murray-Rust peter at ursus.demon.co.uk
Tue Nov 18 23:00:36 GMT 1997


At 12:28 17/11/97 -0500, David G. Durand wrote:
>I want to respond to the "meta-proposal" a bit, because I disagree with
>some of the axioms, and the proposed procedures. I don't have time or
>energy right now to respond to the specific proposal, though I may well do
>so later (based on my own, somewhat divergent, axioms).
                             ^^^^^^^^Good!^^^^^^^^
They may be preferable to mine :-)

>
>At 6:45 PM -0000 11/15/97, Peter Murray-Rust wrote:
>><LIST>
>>  <AXIOM>In any of these cases there is no general solution acceptable to
>>everyone
>>  </AXIOM>
>>  <AXIOM> If no attempt is made to address these problems we shall either
>>end up with a Babel of incompatible solutions, or wait feebly for some
>>powerful autonomous entities to dictate a limited set of actions.
>>  </AXIOM>
>
>Not necessarily. In fact, for many problems the correct response is to
>ensure that the stylesheet ans processing specification langauges can
>_implement_ each of the specific solutions desired, _without_ forcing the
>specific solutions on whihc divergence of opinion may exist. More on this
>with the "PI" axioms.

I have thought about this and have taken it to heart. I agree that
stylesheets are usually preferable to PIs. I shall therefore mentally look
for stylesheet-based solutions (or attribute-based solutions) before
PI-based solutions.  

The XSL stylesheet proposal is still very young. I have read the proposal
carefully and tried to understand how to implement it - I've got about
halfway. the problem (for me) is that it is very paper-oriented (or
paper-like screen displays) and doesn't easily have a mechanism of
implementing BEHAVIOR (which an XLL processor should have). It also doesn't
specify anything about transformation (i.e. XML2XML). It will also be a
little while before it's out fully.

>
>>  <AXIOM> We have to be careful to avoid the 'only processable with
>>software X' syndrome</AXIOM>
>
>Yes. The way to do this is to _avoid_ PIs as much as possible. PIs that are
>required to interpret a document correctly are _inherently_
>anti-portability, since the rule for PIs is that _any application_ should
>be free to ignore them without changin the meaning of the document. The use
>of SGML's PI syntax in XML is a not a good model for the use of PIs in
>general, since they are being used in XML as a syntactic "escape hatch" for
>compatibility with SGML. It would not be necessary (or desirable) if XML
>were not (to some very small extent) changing SGML facilitied (as with
>specifying the character encoding of entitites in PIs, rather than an SGML
>declaration).
>
>If XML had been able to add declarations to SGML, that would have been done
>instead of using the PI syntax.

If I understand this, you are saying that PIs are required to get XML to
work (e.g. <?XML?>, namespace etc.) but they are too dangerous for normal
mortals. I can go along with that view, but the spec-authors should
restrict the PI-targets to XML.  The message the current spec gives is:
	- Here are PIs. Use them if you want. 
What (perhaps) they should say is:
	- PIs should be reserved for things we (the XML-WG) can't do in XML any
other way. Using them otherwise can seriously damage your readers' health.

>
>>  <AXIOM> There is a critical mass of readers of this list who feel the
>>need to address the problem.  </AXIOM>
>
>Without a problem statement I'm not sure how to judge this, but it may well
>be true.
>
>>  <AXIOM> Anyone can use any PIs they like in their documents for whatever
>>purposes they like without breaking the spirit of XML.  </AXIOM>
>
>This is assuredly incorrect. PIs are intended for use in the case where a
>practical _use_ of a document with _particular software_ requires
>additional information that _should not_ have been indicated ina structural
>description of the content. A paradigmatic example is the occasional need
>to insert a page or column break in order to get acceptable formatting in a
>particular processing situation (including: software, stylesheet, output
>device). This is not information that _should_ be encoded in the abstract
>representation of a document, but _may be essential_ for "getting the thing
>to print right".

Understood. Even in TeX you have to fudge it occasionally. But quite a lot
of XML applications won't have any pages. IMO XML is not yet prepared for
the non-document-oriented applications. We shall want to do other things
with XML documents than read them. :-) Stylesheets are very highly oriented
to typesetting on paper.

>
>>  <AXIOM> That processing software need not (and so far won't) take any
>>notice of these (or perhaps any) PIs
>>  </AXIOM>
>
>This is certainly essential. If you are saying something about you document
>that you can imagine being useful to some software that you aren't using
>right now -- then it should probably be in the markup. PIs are for things
>that can be ignored without changing the interpretation of a document.

Yes. Actually that was true of my proposals as well. The PI was modifying
the production of porridge. If the document had gone to a Postscript
formatter instead, it wouldn't have changed the meaning of the document,
just not cooked any porridge. 
>
>>  <AXIOM> If a few people find a way of doing something that works for
>>them, and isn't against the spirit of the XML specs, then flaming their
>>ideas is pointless.</AXIOM>
>
>Even this is not necessarily true -- attacking the dissemination of false
>or bad ideas is _never_ pointless, in that dissemination of bad information
>(even if it serves a local porpose adequately well) can seriously mislead
>people. For instance the use of styles in word-processing programs is
>usually a very good idea. The fact that in some instances direct formatting
>may work out, or even work better, should not stop people from quarreling
>with public assertions about the utility of stylesheets based on those
>situations.
>
>To the extent that these axioms seem to be intended to rule out
>disagreement of the merits of future proposals, I must take immediate and
>strong exception to them. It's not possible for a responsible discussant
>who disagrees with a public proposal of working practice to remain silent
>on the topic. "Flaming" is usually not responsible discussion, but
>principled disagreements should be expressed so that the issues are clear
>to all.

Good. The axiom might benefit from revision or deletion - we'll see...

>
>></LIST>
>><NOTE>The proposal I really want to address is, like Month Python's joke,
>>so potentially dangerous that I dare not reveal it yet. The proposal here
>>is also important to me - perhaps to others - and I hope servers as a
>>useful example. It is NOT in a finalised form, but as can be seen from the
>>meta-proposal, there is a method for referring to the a 'pseudo-final' form
>>that is, at least, usable.
>></NOTE>
>
>This makes me nervous

Wasn't meant to. I am more nervous of implementations which take place
without any discussion at all. 

>
>><META-PROPOSAL>
>>That a PI of the form <?XDEV?> is 'reserved' by members of this list for
>>PI-based proposals on this list. [We cannot use XML-DEV as 'XML' is rightly
>>reserved.]
>
>We can certainly do this -- but as I said above, there are good reasons to
>oppose the use of PIs for _any_ use that affects the semantics of
>documents.

<REVISION>
That the characters XDEV be used in places such as Attribute names, values,
elements, namespaces and (in the last resort) PIs where they serve to
clarify the semantics by referring to discussions on this list
</REVISION>

>
>For example, even the proposed namespace PI would be vulnerable on this
>account, except for the facts that:
>
>   1. It's intended for use in _experiment_ with a proposed _extension_ of
>XML. (In other words, the PI, should it be generally accepted for use with
>all interested XML applications, would become part of XML).

Understood. And I am experimenting with it. It does great things for me and
JUMBO. 
>
>   2. The prefix can be processed (and thus, the semantic information
>accessed) _without_ software having to be aware of the namespace PI. In
>other words, the PI can be treated as equivalent to a comment describing
>the proposed intent of the tags that share a prefix. (In other words, you
>can ignore the namespace PI, and still detect the semantic distinctions in
>the document)

I don't understand this. My understanding of the namespace proposal is that:
<?xml:namespace HREF="foo.org/bar.xml" AS="FOO"?>

identifies a namespace FOO used as FOO:xyz in certain names, etc. The HREF
points to a 'schema' for some undefined purpose. When a processor (not a
parser) finds an element of type <FOO:plugh/> it can:
	- treat it as semantically void
	- realise from the PI that bar.xml might say something useful about it
(this is what JUMBO does)
	- realise that it knows privately about the FOO namespace and looks up
FOO:plugh
	- matches the action with FOO:plugh is a stylesheet

If you are treating the PI as a comment, but relying on a stylesheet, why
use the PI at all. (JUMBO uses the PI, because it can't use stylesheets for
some of the things it wants to do).

>In the long run this may (or for a number of reasons may not) be true.
>However, bad ideas that are initially plausible but unworkable in the long
>term (e.g., from a related, but different doamin, the creation and
>management of large structured information cropora in raw HTML) would get
>an artificial (and community-harmful) boost if an effective social
>convention forbidding disagreement were in effect.

Perhaps. The idea was to create spaces on this list where people with a
common vision can devise approaches to which they can make semantic
reference. At present I'm asking whether that's a good idea. If enough
people think it is, then I would hope the discussion would be ignored by
those not interested. Those who object to it can start their own parallel
discussion - no harm in that.

As you can see - and I'll elaborate later - I think there is virtue in
trying out new ideas in public, even if they have potential flaws or
limitations. HTML is a good example; it was designed to be tolerant of
broken systems, implemented to be even more tolerant.  Even in XML,
everything will not be gold plated.

>
>I agree that polite, reasoned disagreement is better than flaming
>(impolite, ad-hominem disagreement) but in the intellectual world the unfit
>perish faster under the lash of criticism.

We'll find somewhere in the middle :-)

	P.


Peter Murray-Rust, Director Virtual School of Molecular Sciences, domestic
net connection
VSMS http://www.nottingham.ac.uk/vsms, Virtual Hyperglossary
http://www.venus.co.uk/vhg

xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev at ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/
To (un)subscribe, mailto:majordomo at ic.ac.uk the following message;
(un)subscribe xml-dev
To subscribe to the digests, mailto:majordomo at ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa at ic.ac.uk)




More information about the Xml-dev mailing list