[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] Re: XCatalog proposal draft 0.1
Murray Altheim wrote: > John, this is no criticism of the proposal itself, but 'rough consensus' > requires that you have participation. Because this mailing list is not > part of any recognized standards activity, there is no procedural method > for creating standards, nor is there any obligation for either comment > or recognition of anything that occurs on this list from its participants. My remarks about "rough consensus and working code" in a week or two were meant as a mild satire on how long-drawn-out the IETF process (which purports to adhere to that meta-standard) has become. XML-Dev work, as Peter says, is standards development without a net, though whether he means a tennis net or an acrobat's net, he doesn't say. > > The *draft* number is 0.1, but the standard will be 1.0 when it is > > a standard. > > Again, discussion of standardization and version numbers is rather out > of place, unless I'm mistaken and this has already been proposed to a > standards body. If so, my apologies. It hasn't. But ehat is important about standards IMHO is not who promulgates them, but whether they gain wide acceptance. SAX is a paradigm in this respect. > An XML 1.0 parser that does anything at all with catalogs is going beyond > the spec, but is not out of compliance. The question was open. I would > recommend any declaration that allows for a publicId should allow for > catalog resolution. Yes, but limited to providing resolution of the PublicId into a SystemId. > Because the XCatalog proposal follows Socats, you > should simply rely on the features of Socats as appropriate to XML and > not concern yourself with existing implementation support. IOW, you can > rely on whatever showing up in a final draft of the Socat proposal as > being the expected set of resolution features. I'm sorry, but I don't follow these two sentences. Is 9401:1997 in imminent revision? > All of this in the end > will need to be hashed over by a lot of people. I would suspect that > if ENTITY and NOTATION are in 9401, they should be XCatalog, otherwise > transformation from a Socat format to XCatalog would result in loss of > information. > > I'd suggest adding: > > Notation ::= "NOTATION" WS Name WS SystemLiteral > > Entity ::= "ENTITY" WS Name WS SystemLiteral > > or at least discussing things with the Socat editors to garner what will > be in the final. (Last I heard this was still in progress.) This is a fundamental difference between XML and SGML. In XML, there is no natural concept of a "storage object identifier" other than a URI, and it is prescribed that SystemIds are URIs. There is no need to provide mechanisms to map URIs into other URIs within the XML world, because the URI world already has such mechanisms, like URN resolution and HTTP permanent redirection. Any such Notation and Entity declarations would override the fixed interpretation of XML SystemIds and DTD declarations, which seems to me unnecessary and unacceptable. > As for searching, it would be better if you simply referenced the Socat > spec as much as possible. Behaviour should be identical as much as possible. I believe that I have restated it. After all, by that token the XML spec could have just been: See ISO 8859 with the following exceptions and limitations (append James Clark's Note here). But it wasn't, and for good and sufficient reason. 9401 contains many features irrelevant to XML. > As regards name resolution, I'm not aware that XML should be substantially > different than SGML. If the features exist, it should be the same, IMO. XML has a different and more restrictive concept set. > > > Also, have you verified that this section is 100% compatible with > > > SO Catalogs? IMHO, it should be, so that one can implement a general > > > catalog engine that is independent of the syntax. > > This was the point I made in a previous paragraph. I *intend* the algorithm to be the same, and I *believe* it to be the same, modulo the issue of SystemIds vs. storage identifiers, but *verification*? The 9401 algorithm is by no means expressed in a formalism that would lend itself to verification, and IMHO it is not particularly clear even as prose. You ask more than can reasonably be provided. > > There are a few problems. XCatalogs as specified are case-sensitive > > whereas OASIS TR 9401:1997 is not, but all actual catalog examples > > use uppercase only AFAIK. Also, I have imposed a slightly more > > restrictive comment syntax, requiring whitespace both before and > > after all comments, except comments at BOF or EOF. This too > > seems to conform to actual practice. (Note that the formal grammar > > of TR 9401:1997 is *not* authoritative about comments: 8879 is.) > [comments on search algorythms elided...] > > Remember that catalog support, the individual specs for URIs, URNs, URLs, > etc. are outside of the scope of XML. The only part of XCatalogs that > should be case sensitive is the markup syntax itself. Catalog content > is like any other XML attribute content -- free of restraints other than > those imposed by whatever attribute type is declared. Case is not > part of this for CDATA. I'm talking about the Socat-compatible syntax. 9401 says that Socat keywords are case-blind, but XCatalog makes them case-sensitive and upper-case, in conformity with the usual XML rules for stuff taken directly from SGML. All examples of Socats known to me, including the examples in the spec, use upper-case keywords, so this seems a small incompatibility. > > 1. Introduction > > If this is to go ahead as a formal proposal, I surmise you will be > including definitions (eg., 'Socat', etc.) and a list of resources. Probably. > > 2. Example > > Why in your example is the original comment rendered as element > content? Was this intentional? In my implementation, I merely > used XML comments, as '-- text --' translates to '<!-- text -->' > in XML. Because XML processors are free to strip comments (clause 2.5), so that any application that wishes to process the documentation (for example, to pretty-print catalogs) may not be able to see documentation in the form of XML comments. A similar rationale applies to the XSC:Doc element. > > Other ::= Name (WS Name)? (WS SystemLiteral)* > > I'm looking over the 9401 TR and noting that you're mirroring the syntax > of most of that document. I understand the rationale in not supporting > some of the more arcane or inapplicable features therein, but I'm not sure > that the expression for 'Other' entries will suffice. Given that catalogs are > often (in practice) delimited by line breaks, If so, such software is noncompliant to 9401:1997. > and 'Other' allows for optional > Names and SystemLiterals, how will a Socat-to-XCatalog parser/translator know > it has reached the end of a an 'Other' entry given that it is undefined? Not so. See the 9401:1997 grammar, the rule named "other information". I am tracking this rule fairly exactly, modulo my marginally different treatment of comments. The Other rule says: a keyword (Name syntax), an optional subkeyword (Name syntax), and optional quoted strings. So the next non-quoted-string will be the beginning of the next entry. This is true for both my version and 9401's, and shows that 9401 was *designed* to allow Socat processors to skip information they do not understand. > Remember that catalog files currently enjoy support only insofar as they > are 'standardized' within the industry. If someone wants to use the > current Socat syntax in their own custom way, this obviously would have > no wider use than their proprietary software. This requires no modication > to the Socat spec, and I would strongly urge that the XCatalog proposal > not be polluted with featuritis. If someone wants to use an XCatalog > element in their own application, there would be no required change to > the XCatalog spec, and indeed, to do so would require implementors to > support this feature. The point is that the instance syntax currently requires a specific root element, XCatalog. I am proposing (in draft 0.2) that this be dropped, so that XCatalog instance recognition is done by searching a random document for the appropriate element GIs; any XML instance is an XCatalog iff it contains the right elements. (Or even if it doesn't; that just makes it an empty XCatalog.) > I'd remove the version number, write it up as an IETF > Internet Draft and post it. Which version number, the draft number, or the Version attribute of the XCatalog element (now on my hit list anyway)? > If I saw this as an IETF Internet Draft, I'd > be happy to post a notice to XML-SIG (and I think I could get Jon to > post it to the WG) so you'd at least get the attention of those > interested so they could comment on this in the IETF. I'll try to make this happen. > As part of a > discussion on XML-DEV, it has the same priority for me (and probably > others) as the XSchema proposal: a good, necessary feature, but not part > of an extended activity that I can justify easily to my boss given it > has no product. Point taken. -- John Cowan http://www.ccil.org/~cowan cowan@c... You tollerday donsk? N. You tolkatiff scowegian? Nn. You spigotty anglease? Nnn. You phonio saxo? Nnnn. Clear all so! 'Tis a Jute.... (Finnegans Wake 16.5) xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@i... Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@i... the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@i... the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@i...)
|
PURCHASE STYLUS STUDIO ONLINE TODAY!Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced! Download The World's Best XML IDE!Accelerate XML development with our award-winning XML IDE - Download a free trial today! Subscribe in XML format
|