XCatalog proposal draft 0.1 [From Murray Altheim]

[Peter Murray-Rust]

>
>Date: Fri, 24 Jul 1998 15:27:30 -0700 (PDT)
>From: Murray Altheim <altheim at mehitabel>
>Subject: Re: XCatalog proposal draft 0.1
>To: cowan at locke.ccil.org
>Cc: xml-dev at ic.ac.uk
>Mime-Version: 1.0
>Content-MD5: O2iZwUR+crikepw8yyr+gA==
>
>John Cowan <cowan at locke.ccil.org> 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&#64;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 at ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/
To (un)subscribe, mailto:majordomo at ic.ac.uk the following message;
(un)subscribe xml-dev
To subscribe to the digests, mailto:majordomo at ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa at ic.ac.uk)