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

[Peter Murray-Rust <peter@ursus.demon.co.uk>]

In this posting I make a proposal for the treatment of a certain class of
XML files. I offer this in the belief that there is a subset of the XML
community who will find this proposal useful and may wish to refine it
gently.  There is also a meta-proposal for the use of a PI-target
associated in a general way with this list. This PI-target can in principle
could be used for a wide class of applications. If there are people who
believe that the *meta-proposal* is harmful or beneficial to the XML
community, I'd be grateful for their views posted to the list. If they
believe that the meta-proposal is acceptable, but they don't like the
proposal, then they can delete subsequent correspondence on the proposal
before reading.  Constructive and Destructive criticism of the
meta-proposal is appropriate; destructive criticism of the proposal is
pointless.

<BACKGROUND>
A considerable amount of decision-making in XML is left 'to the
application' (i.e. some or all of the processing software after the
document has been parsed. In some cases the whole
authoring/distribution/parsing/application process is under the effective
control of some 'organisation'. They will develop their applications to be
consistent with the authoring tools and the document instances; this need
not concern us.

A number of groups and individuals are, however, proposing XML
'applications' where there is unlikely to be a single 'application' for
processing. Moreover, many of these may be DTD-less in some way and may
also not use style sheets.  There is often an implied need for these
'applications' to set constraints on the processing software in ways that
are not covered, and not likely to be covered, by the formal specs.

In other cases the specs provide syntax, but no semantics, for certain
important operations. I believe that there may be cases where many people
want a particular generic behaviour where a broad consensus can be obtained
and which need not affect the formal spec development.
</BACKGROUND>

<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>
  <AXIOM> We have to be careful to avoid the 'only processable with
software X' syndrome</AXIOM>
  <AXIOM> There is a critical mass of readers of this list who feel the
need to address the problem.  </AXIOM>
  <AXIOM> Anyone can use any PIs they like in their documents for whatever
purposes they like without breaking the spirit of XML.  </AXIOM>
  <AXIOM> That processing software need not (and so far won't) take any
notice of these (or perhaps any) PIs
  </AXIOM>
  <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>
</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>

<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.] 

That anyone can post a proposal to this list for the use of this PI.

That any author can include an instance of such a proposed PI in their
document.

That any writer of application software can write software to process such
a PI.

That both of these should refer to an appropriate URL on this list's
archive discussing outlining the use of this PI.

That if someone doesn't approve of a proposal they ignore it rather than
flaming it. The fittest ideas will survive.

</META-PROPOSAL>

<EXAMPLE>
<![CDATA[
Assume a porridge cooker (a real piece of equipment) is controlled by an
XML-document. (This is not governed by the current XSL proposal.)

FatherBear proposes a particular use for XLL's ROLE attribute when used to
link to <PORRIDGE> elements. There is much discussion on XML-DEV.
FatherBear's views are too hot and do not find favour.
MotherBear proposes an alternative. There is much more discussion but it
doesn't get much further. MotherBear is cool, but too cool.
BabyBear makes a third proposal. This is 'just right' for many people (but
not everyone, of course). Various people suggest that they could work along
with BabyBear's proposal. BabyBear and others hack it into shape.  A set of
suggested guidelines is posted to XML-DEV.
Goldilocks E-pubCorp says that its userAgent will now support BabyBear's
proposal, and bolts it into their authoring tool.
[None of this need come anywhere near the XML-WG, XML-SIG, W3C or anything
else.]

The documents authored according to the BabyBear proposal might look like:
<MEAL>
  <PORRIDGE>
  <?XDEV HREF="http://www.lists.ic.ac.uk/hypermail/xml-dev/9711/6789.html"
    PORRIDGE-COOKER="BabyBear"?>
    <OATMEAL>
      <UNITS>kilograms</UNITS>
      <VALUE>100</UNITS>
    </OATMEAL>
    <TIME>
      <UNITS>minutes</UNITS>
      <VALUE>20</UNITS>
    </TIME>
    <NACL>NULL</NACL>
    <RECIPE XML-LINK="SIMPLE" HREF="bears.org/recipes/porridge.xml"
ACTUATE="AUTO">
  </PORRIDGE>
  <?XDEV PORRIDGE-COOKER="NULL"?>
</MEAL>

The JUMBO porridge-cooker (from all good e-marts) is XML-aware and
recognises the XDEV PI. The author of PORRIDGE.java makes sure that the
software is compliant with the proposal in BabyBear's posting to XML-DEV.
The JUMBO corp publishes some amendments to the cooking process (e.g.
<FIRE-WARNING>).
  
That's all, folks.  Nobody *has* to do any of this. FatherBear teams up
with the BigBadWolf corp. Their ideas do not flourish. They simply miss out
on porridge. 
]]>
</EXAMPLE>

Now a real proposal.

<BACKGROUND>
I wish to display objects on the screen in a way not supported by XLL and
XSL. Specifically I have an element (object) which may be displayable on
its own ('standalone') or may be displayable in the context of another
object (perhaps a parent container). An example might be a PERSON in an
ORGCHART. (Actually I want to display ATOMS in MOLecules, of course). I
might wish to create an XML-LINK to a PERSON which displayed that PERSON.
Alternatively I might wish to create a link to that PERSON for display in
the context of the org-chart (i.e. when I actuate that link, the org-chart
is displayed and all other linked PERSONs.

I wish to use the BEHAVIOR attribute of XLL for this. No values for this
attribute are defined at present, and some XML-SIGers have suggested that
there will never be a definitive list. If values are chosen at random by
the community, then in a year's time we shall have chaos on the behaviour
attribute. So this proposal can be seen as suggesting a wider discussion of
possible values for BEHAVIOR. 

Note that we don't all have to agree :-). It is perfectly possible that two
incompatible proposals appear. Both can use XDEV, but point to different
URLs (and hopefully have different mnemonics). No problem. A user agent can
implement on, both or neither. What I want to avoid is nine-and-sixty ways
that BEHAVIOR is used with no public specification of any semantics.

</BACKGROUND>
<PROPOSAL>
That two attribute values for XML-LINK's BEHAVIOR attribute be recognised
through an XDEV PI:
	BEHAVIOR="DisplayStandAlone"
	BEHAVIOR="DisplayInContext"
That for the second option an additional attribute CONTEXTREF is required,
whose value is a valid URL and points to the XML element providing the
display context of the current element.
	The actual details of display are application (and possibly stylesheet)
dependent.
</PROPOSAl>
<NOTE>
*This* proposal is identifiable through
HREF="http://www.lists.ic.ac.uk/hypermail/xml-dev/9711/xxxx.html"
(where xxxx represents the actual address of *this* hypermail (e.g. 6789 :-)

A user agent can be given the option of operating these semantics by a PI
of the form:
  <?XDEV HREF="http://www.lists.ic.ac.uk/hypermail/xml-dev/9711/6789.html"
    XML-LINK-BEHAVIOR="ContextDisplay"?>
and can revert to the default or previous semantics by:
  <?XDEV HREF="http://www.lists.ic.ac.uk/hypermail/xml-dev/9711/6789.html"
    XML-LINK-BEHAVIOR="Default"?> <!-- or "Off", "Previous", etc. -->
</NOTE>

<EXAMPLE>
Note that the BEHAVIOR attribute is 'inherited' by all the PERSONs (see XLL
spec).

<![CDATA[
  <PERSON XML-LINK="SIMPLE" HREF="boss.xml" BEHAVIOR="DisplayProminently"> 
  <?XDEV HREF="http://www.lists.ic.ac.uk/hypermail/xml-dev/9711/6789.html"
    XML-LINK-BEHAVIOR="ContextDisplay"?>
<PROJECT XML-LINK="EXTENDED" BEHAVIOR="DisplayInContext">
  <PERSON XML-LINK="LOCATOR" HREF="fred.xml"
CONTEXTREF="saltmines.xml#DESCENDANT(1,ORGCHART)"/>
  <PERSON XML-LINK="LOCATOR" HREF="wilma.xml"
CONTEXTREF="saltmines.xml#DESCENDANT(1,ORGCHART)"/>
  <PERSON XML-LINK="LOCATOR" HREF="sally.xml"
CONTEXTREF="galleys.xml#DESCENDANT(1,ORGCHART)"/>
  <PERSON XML-LINK="LOCATOR" HREF="sue.xml" BEHAVIOR="DisplayStandAlone"/>
</PROJECT>
  <?XDEV HREF="http://www.lists.ic.ac.uk/hypermail/xml-dev/9711/6789.html"
    XML-LINK-BEHAVIOR="Off"?>
</PROJECT>
]]>

The display attribute for boss.xml is not activated by this proposal (there
may be a default local protocol for displaying bosses.) The PI switches on
a display protocol whereby the team members Fred, Wilma and Sally  are
displayed in the context of their org-charts (in this case different). Sue
is displayed standalone. [The user agent knows how to display objects
standalone and in the context of other objects. Note that this can be a
fairly generic mechanism - JUMBO acts on any objects which provide a
display() method - not just PERSON. It also has/will_have a
highlightInContext(Node n) method for displaying *this* in the context of
Node n.]

</EXAMPLE>

	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@ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/
To (un)subscribe, mailto:majordomo@ic.ac.uk the following message;
(un)subscribe xml-dev
To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)