[dsdl-discuss] Altered requirements for Part 0 Framework?

I think we are doing things in the correct order by getting Part 4 VCSL solid before
setting Part 0 Framework in stone. (It helps us scope Part 0's purpose by attrition:
it must have the things that are needed but which have not been handled by other parts.)

I think there have been two new factors emerging, which impact Part 0:
  - VCsL can do schema selection, which reduces the need for Part 0 to also do it
  - requests for validation of non-XML formats: SGML from Martin, for example,
    and the experiemental concurrent languages from other people

This makes me wonder whether the Xpipeline/Schemachine/Ant/XVIF approach
is now completely redundant (having been superceded by VCSL) I wonder whether
Part 0 should instead concern itself with input/output and configuration issues.
I hope I am not giving Eric a heart attack!

The kinds of issues I am thinking of relate to how to declare the peripheral information
that will be required to get data from the notional standard input (IYKWIM) into
XML.

If that were taken as the functional overview for Part 0, then it would address things
like
  - when reading XML, how to set the xml:base, whether to perform early xml:includes,
    whether to validate using an existing DOCTYPE declaration, whether to apply
    default entity set definitions, whether to use an OASIS XML catalog
  - when reading SGML, which SGML declaration to use, whether to use an OASIS
    SGML catalog, which concurrent markup is active (in theory)
  - when reading some other notation, how to identify the processor to view the data
    as XML.
  - how to set implementation-dependent features (i.e. SAX style, different SP warnings,
       recovery strategies)

I think there has been a real problem with SGML systems that in order to parse
you really have had to use some non-standard declarations. This severely reduces
portability and ease-of-use. For example, specifying the location of a catalog file.
Of course users *can* do this by command line switches, config files, dialog boxes,
etc. The problem is that users *cannot* do it in a standard, portable way, and this
is one place where I think we need to change our way of thinking from the old
SGML "the system identifiers will need to be customized on every platform anyway
so why worry about it" attitude.

One aspect of the recent discussion of concurrent markup is that maybe we should be
careful to talk about "XML views" of documents rather than plain "XML" or "XML
infosets". An XML view of data can trivially be implemented as an XML document,
but it might also be a set of pointers to some concurrent spaghetti accessed as a DOM.

If Part 0 dropped any aspect of selecting schemas, leaving that to Part 4, the question is
does that make DSDL monolithic, in that a DSDL system would then require Part 4.
Also, if Part 0 dropped schema selection as its main role, Part 4 will have to have
the ability to validate against multiple schemas (e.g. RELAX NG + Schematron, or
James' 3 RELAX NGs for XHTML). Which is not a bad thing.
   
Cheers
Rick Jelliffe

--
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)