[dsdl-discuss] Re: Concurrent (overlapping) structures

> First, let me apologize if I was a bit huffy in my previous
> post. I was frustrated by a bug at the
> time.

No huff detected ;-)

> When I said that concurrent markup was a niche requirement,

I'm not sure just how 'niche' it is. As a historical note it's interesting
that the TEI guys reached for CONCUR right from the start for modelling
common features of humanities texts. Martin's mentioned the horrific world
of loose-leaf publishing, I have already suggested (from my own experience)
that overlapping structures are widespread in publishing, and other work
(e.g., Patrick Durasau's - see http://www.sbl-site2.org/Overlap/) together
suggests that overlapping structures are the norm for at least a significant
minority of documents.

As an aside, I wonder what course things would have taken if JC had
implemented CONCUR in sp ...
 
> it was not meant to be dismissive
> but to emphasize why a modular approach like DSDL is so
> important: there are so many niches
> or specialist needs. A convenient framework makes it
> convenient to create specialist validation
> languages. Non-nesting structures is a very good example of this.
>
> ISO is in a good position for this: the W3C effort is based
> on "how can we get the broadest possible
> single schema language" which precludes specialist
> requirements. ISO, on the other hand, can
> get agreement for fairly small specialist languages: in
> particular, we can focus on the requirements
> of people who work with text such as publishers of various kinds.

Agreed.
 
> So a more polite response than last time would be:
>
> 1) You can validate almost any constraint with Schematron
> (especially, Schematron + RELAX NG
> + some kind of datatyping) including non-nesting structure
> constraints. So DSDL starts off *way*
> ahead of DTDs or XML Schemas. However, Schematron schemas may
> be ugly and algorithmic:
> good for validation and for human messages but not reusable
> in the way that a more domain-specific
> language would be.

Yes, though I'm not quite sure what extra validation abilities RNG or
datatypes add to Schematron (though that's another discussion).
 
> 2) Because DSDL provides a framework, systems based on
> transforming the document in various
> ways before validating it are very possible: in fact, that
> you can view two parts of DSDL as doing
> that already (i.e. Part 4 Validation Candidate Selection
> Language and Part 8 (?) Architectural
> Forms(?)). So that is more systematic than XML Schema's
> too-primitive <appinfo> elements.

Yes, it seems likely the way forward is to have some means of expressing
overlapping structures in a (possibly non-XML) syntax that is then boiled
down to XML. Expressing the grammars is trickier.

> 3) If you have a specialist need that you think is general,
> then the best thing is to get some
> running code to fit into, in particular, RELAX NG, such as
> James suggests, and then joining
> the ISO effort to get it introduced into ISO DSDL. To say
> "DSDL falls short because it
> doesn't provide X" really translates to "someone else should
> get X standardized": but DSDL
> languages (and ISO SC34 standards in general) are typically
> user/developer driven and need
> a champion: *you* should get it developed and standardized!

It's true as a relative ISO newbie I'm not entirely sure how I 'should' be
contributing to this discussion list, but I certainly don't have the
resources (not least, coding skill!) to retrofit overlapping validation into
Trang (or whatever) before suggesting it might be desirable for DSDL to
support such a thing.

At present I can only really contribute as a 'user' (or, to be more precise,
as a self-appointed representive of some people I hope will be users -
including my company's clients). Is it not a valid contribution to
articulate to this list what I think their concerns/requirements might be,
for discussion?

- Alex.

--
DSDL members discussion list
To unsubscribe, please send a message with the
command  "unsubscribe" to dsdl-discuss-request@dsdl.org
(mailto:dsdl-discuss-request@dsdl.org?Subject=unsubscribe)