[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] Re: XCatalog proposal draft 0.1 [From Murray Altheim]
> >Date: Fri, 24 Jul 1998 15:27:30 -0700 (PDT) >From: Murray Altheim <altheim@mehitabel> >Subject: Re: XCatalog proposal draft 0.1 >To: cowan@l... >Cc: xml-dev@i... >Mime-Version: 1.0 >Content-MD5: O2iZwUR+crikepw8yyr+gA== > >John Cowan <cowan@l...> writes: >> Lars Marius Garshol scripsit: >> >> > I have now implemented support both for SO Catalogs and the XML >> > version of XCatalogs in xmlproc 0.50, which I released earlier >> > today. The support is still rather experimental, and does not >> > handle entry conflict resolution correctly. >> >> I propose something one week, rough consensus emerges the next >> week, and working code a week or two later: such is the Internet >> freeware development community. Peace, it's wonderful! > >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. > >> > Once support for SO Catalogs was in place XCatalogs required >> > just 20-30 lines. :-) >> > >> > > <Extend Href="http://www.w3.org/xcatalog/mastercat.xml"/> >> > >> > A small nit: ^ should be HRef, of course. >> >> I disclaim all efforts to set capitalization standards. Personally, >> I like all-uppercase element names and all-lowercase attribute names. > >I'm not sure that 'HRef' is any preferable 'Href'. Both have precedent. >If it came to a vote, I'd probably go with the camelcase of 'HRef', but >so long as there is consistency, I don't care particularly. I think the >proposal as posted is fine, although I'd change 'PublicID' to 'PublicId' >for the same nit reasons you used 'HRef'. 'Identifier' is one word, and >that fits in with the camelcase usage everywhere else in the XML spec. > >> 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. Note that even W3C does not produce >'standards' (but rather 'recommendations'), as they are not a standards >body, rather an industry consortium. > >[...] >> > Also, what about the more controversial parts of >> > SO Catalogs such as ENTITY, NOTATION and DOCTYPE? I haven't made up >> > my own mind about these yet, but it would be nice to hear some other >> > opinions on this. >> >> A (validating) XML parser that respects any of these is out of compliance with >> XML 1.0, so I ignore them. Their effect (loosening the bindings >> between XML objects and external objects) can be achieved by making >> the corresponding declarations in the DTD or instance refer >> to public IDs in some catalog. > >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. 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. 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.) > >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. >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. > >> DTDDECL does the same thing as PUBLIC in an XML context, and I thought >> of supporting it for backward compatibility, but I realized that >> backward compatibility is pointless, since DTDs are almost always >> either XML or SGML and rarely both. So we might just as well treat XML >> DTDs just like all other external entities, using PUBLIC. > >You might note that James Clark has removed support for DTDDECL in SP. I'm >guessing he might know about this than you or I, and possibly DTDDECL will >be removed from Socats. Just a guess. > >[...] >> > 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. > >> 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. > >> > >If both syntaxes are supported, should Delegate and Extend entries >> > >be allowed to refer from one syntax to another, or should Socat >> > >catalogs refer only to other Socat catalogs and ditto for XML >> > >instance catalogs? > >If in the end there is XML catalog support for both syntaxes, I would >assume that a catalog parser would import a catalog into an application, >and its internal representation would be independent of the source format. >Restrictions as stated above are unnecessary and overly stringent, and >in practice would make life rather more difficult for catalog admins. > >> > Another thing: it might be a good idea to standardize environment >> > variables and Java properties that can be used to point to the site >> > socatalog/XCatalog, so that all parsers can use these (if they are >> > present). >> > >> > I'd call the environment variables SOCATALOG and XCATALOG, and the >> > Java properties xml.socatalog and xml.xcatalog. > >This seems out of scope for a catalog proposal. > >Last week I modified the catalog support on my parser to allow for >export of an XML version mirroring the draft. It was not much extra >work. Here are some comments. > >> 1. Introduction >> >> XCatalogs are Web resources (anything from local files on up) >> which contain mappings from public identifiers to system identifiers, >> plus references to other XCatalogs. They come in two syntaxes: >> one which is a subset of Socat syntax, and one which is an >> XML document instance. > >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. > >> 2. Example >> >> Here's an example XCatalog in both syntaxes, for those who learn >> best from examples: >> >> -- catalog for "-//John Cowan" public IDs -- >> BASE "http://www.ccil.org/~cowan/" >[...] >> >> <XCatalog>catalog for "-//John Cowan" public IDs >> <Base HRef="http://www.ccil.org/~cowan/"/> > >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. > >> 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, 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? > >I do think that catalog support in XML is important. Very important here >at Sun. And I do think your proposal is a very good first slice at what >we might need for XML. I would suggest bringing this before a real >standards body such as the IETF or persuading someone to push it as a >work item for the XML WG. I looked at the XML WG Briefing Package and >note that it is not an work item currently. > >A note from you just came in: >> I have had two new thoughts: If XCatalogs don't have to have a >> specific root element like "XCatalog", then it would be possible >> to incorporate them into random XML documents, so that any document >> could serve as an XCatalog as long as it had (empty) elements with >> the right names. Since instance-syntax catalogs have to be fully >> parsed with an XML parser anyway, this is easily enough done. >> >> This requires that XCatalog elements have a namespace of their own, of >> course, which is surely a good idea anyhow. > >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. > >---- > >I hope these comments have been helpful. Written hastily, so note that I >haven't spent any time editing for diplomacy or spelling. Just as an 'if >I were you' aside, I'd remove the version number, write it up as an IETF >Internet Draft and post it. 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. 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. > >Murray > >........................................................................... >Murray Altheim, SGML Grease Monkey <mailto:altheim@eng.sun.com> >Member of Technical Staff, Tools Development & Support >Sun Microsystems, 901 San Antonio Rd., UMPK17-102, Palo Alto, CA 94303-4900 > "Give a monkey the tools and he'll build a typewriter." > Peter Murray-Rust, Director Virtual School of Molecular Sciences, domestic net connection VSMS http://www.nottingham.ac.uk/vsms, Virtual Hyperglossary http://www.venus.co.uk/vhg 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
|