[
Lists Home |
Date Index |
Thread Index
]
From: "Henry S. Thompson" <ht@cogsci.ed.ac.uk>
> "Bullard, Claude L (Len)" <clbullar@ingr.com> writes:
>
> > That's neat, Henry, and I don't mean to be mean-spirited,
> > but is this a "so, but so what?" kind of thing to know?
>
> No offence taken, and yes, it's mostly of academic interest. It does
> potentially feed in to an ongoing discussion (read 'permathread) about
> the pros and cons of layering varying aspects of 'validation'.
Is "ID/IDREF makes XML generation NP-hard" actually the correct conclusion?
Surely it is only fixed (or defaulted?) ID/IDREFs that make XML generation
NP-hard (and is it really IDs, or just IDREFs?). Indeed, one might just as easily
then attribute the ultimate cause to infoset augmentation as much as non-regularity.
Some XSLT-XPath constructs have the same behaviour, as Bob Lyons pointed
out a few months ago for Schematron. However, it seems possible to figure out
which constructs contaminate and to quaranteen them.
> XML generation itself is of more than academic interest -- a good
> authoring tool ought to be able to generate an example of a document
> type or document type fragment, on request.
Surely that depends on the schema itself: how could one generate RDF
on request for example? And since, for content- rather than data systems,
metadata is often more fixed than data, autogenerated skeletons can
present users with complex heads when they may want to be working
on bodies.
The contrasting approach would be templates (and forms)
giving typical and starting positions for editing. (Though, of course, the
two are not really in contention: for example an editor that auto-generated
a template then allowed the developer to trim it into a more useable
template. And a system could potentially sample documents, trim an
existing schema, then generate a template/form, then allow a developer
to customize it.)
Cheers
Rick Jelliffe
Topologi
|
