[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]

  • From: Peter Murray-Rust <peter@u...>
  • To: xml-dev@i...
  • Date: Sat, 25 Jul 1998 14:39:02

proposal draft
>
>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&#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@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!

Buy Stylus Studio Now

Download The World's Best XML IDE!

Accelerate XML development with our award-winning XML IDE - Download a free trial today!

Don't miss another message! Subscribe to this list today.
Email
First Name
Last Name
Company
Subscribe in XML format
RSS 2.0
Atom 0.3
 

Stylus Studio has published XML-DEV in RSS and ATOM formats, enabling users to easily subcribe to the list from their preferred news reader application.


Stylus Studio Sponsored Links are added links designed to provide related and additional information to the visitors of this website. they were not included by the author in the initial post. To view the content without the Sponsor Links please click here.

Site Map | Privacy Policy | Terms of Use | Trademarks
Free Stylus Studio XML Training:
W3C Member
Stylus Studio® and DataDirect XQuery ™are products from DataDirect Technologies, is a registered trademark of Progress Software Corporation, in the U.S. and other countries. © 2004-2013 All Rights Reserved.