Re: [emacs-nxml-mode] Re: Specifying outlining scheme
- On 13/10/12 22:48, RonB wrote:
> Manually changing "nxml-section-element-name-regexp" every time IYes, but I suspect (as you mention later) that most people tend to work
> open a new XML file that has a different associated schema (to be
> excruciatingly explicit: I've read the documentation, schemas are
> being loaded just fine, and are beside the point of the question) is
> an error-prone waste of my time.
with the same schema most of the time. I have no data on this, and I'm
not aware that anyone has ever collected it.
> My question was whether there's some trick to avoiding this that IThis question has come up again and again in various forms over the
> haven't grokked and, assuming not (given I've of course read the
> documentation and far too many web ramblings as well, along with
> goodly chunks of the code), whether anyone has a patch that would
> produce the fairly obvious solution of letting people store (what
> is, after all, meta-schema information that doesn't logically belong
> in an editor variable) this directive inside their .rnc schema file
> as an annotation?
years, right back to the early SGML conferences, and I am discussing it
at length in my current research . As far as I am aware, no-one has
ever come up with a set of semantics or heuristics that will take a
schema and identify "a section element" or "a list element" in a
generalised and extensible manner. There have been many editors that can
be configured (usually externally, by the user or by the person who
administers the software and the documentation management) so that they
"do the right thing" for the schema or schemas in most common use in an
Indeed the Arbortext Editor's Architect program (a DTD/Schema compiler)
asks you after compilation to give the names of the elements types which
hold certain classes of data (section titles, list containers, etc).
Author/Editor (and presumably its current descendants) could take a list
of element types (in an external file) with a line of text explanation
against each, and add this to the Insert Element popup or dropdown so
the user could see what was what.
But an extensible and generic mechanism would require and agreed
(international) ontology for the types of information that needed
binding to concrete element types for each schema. While this is
probably not difficult for the most commonly-used couple of dozen types
of information (headings, paragraphs, lists, captions, etc),the stuff
people want to encode is very extensive, and I suspect that it would
take more time than anyone has available to make it comprehensive. That
shouldn't stop someone trying it for commonly-used types of information,
but they would then need to persuade the editor authors to make used of
this in an extensible manner in their products.
Doing it for Emacs would be a great start, whether it's in nxml, sgml,
xml, html, or any other mode. The principal benefit would be that menus
could then provide actions "New Section", "New List", "New Chapter", etc
(another user requirement identified in my research), and the identity
mechanism would then "know" what element type was required. I'm sure
that Balisage would be an excellent place to announce or discuss the
work :-) Maybe someone has already done this and I've missed it, in
which case I would love to see it.
On 14/10/12 07:56, Dave Pawson wrote:
> Having used nxml-mode since it was released (by James Clark, not
> emacsen) I have never had to use nxml-section-element-name-regexp so
> I can't see what the problem was.
What I have identified is requirements for non-markup-expert end-users:
people who need to create structured documents but who have no interest
in pointy brackets or backslashes and curly braces. I think most people
on this list would classify as markup experts, or at least seasoned
users, who either have no need for this refinement, or are happy enough
with the existing facilities.
Personally, I'm happy with C-x C-e in xml-mode (from psgml) because I
know the DTDs/Schemas I work with, and I prefer working with the markup
visible, and in any case I have bound my most commonly-used key combos
to F-keys. But there is a very large contingent of people in the
non-expert population who want no visible markup *ever*, but still want
the editing software to create a valid instance.
 Draft chapters are slowly appearing at http://wiki.ucc.ie/structed/