Cart
[Home] [By Thread] [By Date] [Recent Entries]
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
|
