[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: RE: Example [Was: Two things to strengthen the spec]
OK. James and Makoto are the doorkeepers for the spec. I was merely leaning on the doorbell. I shall relent. -Mike P.S. Curiously, the namespaces spec never explains what they mean by the actual word /NCName/; yes, the production is there to explain what it is, but the spec never tells you what /NCName/ means in plain language. XML Schema does explain it though. While I think it is safe to rely on other specs for their definitions, sometimes they do not deliver information as well as you'd like. My proposed approach was for the convenience of readers. -----Original Message----- From: Murata Makoto [mailto:mura034@attglobal.net] Sent: Friday, July 20, 2001 6:03 PM To: Michael Fitzgerald Cc: RELAX NG List Subject: Re: Example [Was: Two things to strengthen the spec] Michael Fitzgerald wrote: > I can understand your concern about turning the spec into another tutorial. > I don't want you to do that either. I suggested block definitions as an > enhancement to aid understanding of a broader audience beyond the XML > cognoscenti, making the spec easy to grasp by someone who may be new to XML. > They will appreciate it. But I concede that the tutorial succeeds well for > this imagined broad audience already. Nonetheless, I believe block > definitions would only add about 1-2 pages to the spec's length. Not a dear > price to pay. First, I do not think we should duplicate definitions in other specifications. For example, suppose that we define characters, namespace prefixes, URIs in our spec. Then, careful readers will be confused. When relevant specs are updated, should they continue to use the definitions in our spec or use the revised definitions in the relevant specs? Cheers, Makoto
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC