xml-dev - Re: XCatalog proposal draft 0.1

[John Cowan <cowan@locke.ccil.org>]

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@ccil.org
	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@ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/
To (un)subscribe, mailto:majordomo@ic.ac.uk the following message;
(un)subscribe xml-dev
To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)