xml:dtatts for DTDless XML was Re: Implementations not specifications are the problem

["Jonathan Borden" <jborden@mediaone.net>]

James Clark wrote:

>
> >> "(iii) It doesn't work with streaming output. This is in my view the
most
> >> important technical problem"
> >>
> >
> > Err, so wouldn't it be easier to fix the streaming output systems (I
> > believe Xalan already implements the SAX DeclHandler interface on its
> > default output handler) than to:
> >
> > 1) Create an entirely new specification
> > 2) Update every XML parser and XPath and DOM implementation
> > 3) Deploy the new implementions
> >
> > The problem is in _implementations_ not _specifications_.
> >
> > Perhaps I am missing something?
>
> No amount of fixing implementations will solve the problem.
[...good points snipped...]

Ok if the problem is defined as the ability to 1-pass stream, then this is
true. Like XML Namespace decls which may be at any level, we would have to
allow nested _xml:idatts_ decls (but realize the pain in terms of
_explaning_ XML Namespaces that has been introduced by this slight increase
in complexity).

I think the best argument for _xml:idatts_ is that as you say _this alone_
would allow the representation of an XML Infoset inline as an XML instance,
and allow us to move beyond the DTD syntax ***in the instance*** i.e. to
eliminate the absolute need for an internal subset.

>
> Note that the issue of streaming output is the main reason why namespace
> declarations were allowed to nest rather that being all required up front
> on the document element. See
>
> http://www.w3.org/DesignIssues/Extensible.html#Local

Yes, but while this practice is defensible for streaming applications, it is
not a best practice for human readability. I firmly believe that we should
not loose focus on trying to keep XML human readable, and hence the case
should be made that nesting such decls is not a best practice _unless there
is a good reason to do so_ (note that I always consider a 'best practice'
such a rule meant to be broken)
:
> >
> > On the other hand I _do_ think there is value in 'moving beyond' DTDs to
> > XML syntax schemas. Since you are working with RELAXNG, rather than
> > propose _xml:atts_ which is a partial solution to the problem, will you
> > include the _xml:atts_ proposal as a part of RELAXNG in some fashion?
>
> The RELAX NG DTD Compatibility spec
>
>   http://www.oasis-open.org/committees/relax-ng/compatibility.html
>
> provides a DTD-compatible ID facility.  However, I'm not a big fan of IDs.
> I strongly dislike the kind of redundant markup that ID/IDREF based
linking
> often forces:
>
>   A <termdef id="dt-well-formed">well-formed</termdef> document is...
>
>   A <termref ref="dt-well-formed">well-formed</termref> document must...

I don't see much need for IDREF (as long as we have XLink). I see ID
_solely_ as a way to define "Raw Names" which I do find quite useful. For
example the generated URI Reference:

mid://this-mail-message#dt-well-formed

is often readable by humans as a pointer to something in the document that
describes the datatype 'well formed' and this is how IDs are used in RDDL.
As well RDF uses IDs _purely_ for the purpose of generating URIreferences
(so although Gavin doesn't use this particular idiom, it is in use by
others) We could argue that there are other ways of generating Raw Names but
I would argue that at the end of the day they would be equivalent to IDs.


>
> I prefer something along the lines of XSD identity constraints, except (i)
> it should be specifiable and useable independently of the other parts of
> the schema

The key point for the purposes of this discussion is that the mechanism
should allow adornment of XML instances i.e. inline.

and (ii) it needs to support keyrefs to hierarchichal systems of
> keys. I hope at some point there will be a companion spec to RELAX NG that
> provides this.

The approach taken by RELAXNG is to consider an ID one of a set of datatypes
(a fair approach). This raises the question that if we are introducing
_xml:idatts_ as a way of eliminating the need for DTDs, then why special
case IDs, why not introduce a general in-line datatyping adornment mechanism
e.g.

xml:dtatts="xsd:ID id
            xsd:uriRef href
            xsd:string title"

(xsd namespace used for example purposes)

xmlentity:name="entitydecl"

?is there any real role for NOTATIONS?

So, Simon after considering it overnight I actually agree with what you
propose, but in order to make this worthwhile we need to have the
_capability_ of jettisoning DTDs in all their forms altogether.

Jonathan