Re: [entity-resolution] XML Catalogs 1.1 Committee Specification

[Jirka Kosek <jirka@kosek.cz>]

Norman Walsh wrote:

> Here it is, in HTML. My PDF stylesheet's producing really odd margins,
> I'll work on it asap.

Hi Norm, please find my comments inline:

>       4.4. Suffix Entries
> 
> Suffix entries are provided as a mechanism for matching based on the suffix of 
> an identifier. The typical use case is to match a common entity based on its 
> name rather than its full URI.
> 
> For example, you can match a DTD such as xhtml1-strict.dtd or a schema such as 
> docbook.rng regardless of the full system identifier or URI used in the document
> 
> For example, with this entry:
> 
> <systemSuffix systemIdSuffix="html1-strict.dtd"
>               uri="file:///share/mirrors/w3c/xhtml1/xhtml1-strict.dtd"/>
> 
> any system identifier that ends in “xhtml1-strict.dtd>” will be translated into 

Surplus ">" after "xhtml1-strict.dtd"

>       4.5. An XML Catalog Example
> 
> The catalog files in Example 1, “A DocBook XML Catalog File: docbook.xml.” 
> <#ex.docbook.cat> and Example 2, “A Stylesheet XML Catalog File: 
> stylesheet.xml.” <#ex.stylesheet.cat> are complete examples of XML Catalog files.
> 
> *Example 1. A DocBook XML Catalog File: docbook.xml.*
> 
> <!DOCTYPE catalog
>   PUBLIC "-//OASIS//DTD XML Catalogs V1.0//EN"
>          "http://www.oasis-open.org/committees/entity/release/1.0/catalog.dtd";>
> <catalog xmlns="urn:oasis:names:tc:entity:xmlns:xml:catalog"
>          prefer="public">
> 
>   <group xml:base="http://www.oasis-open.org/docbook/xml/4.1.2/";>
>     <public publicId="-//OASIS//DTD DocBook XML V4.1.2//EN"
>             uri="docbookx.dtd"/>
>     <public publicId="-//OASIS//ENTITIES DocBook XML Notations V4.1.2//EN"
>             uri="dbnotnx.mod"/>
>     <public publicId="-//OASIS//ENTITIES DocBook XML Character Entities V4.1.2//EN"
>             uri="dbcentx.mod"/>
>     <public publicId="-//OASIS//ELEMENTS DocBook XML Information Pool V4.1.2//EN"
>             uri="dbpoolx.mod"/>
>     <public publicId="-//OASIS//ELEMENTS DocBook XML Document Hierarchy V4.1.2//EN"
>             uri="dbhierx.mod"/>
>     <public publicId="-//OASIS//ENTITIES DocBook XML Additional General Entities V4.1.2//EN"
>             uri="dbgenent.mod"/>
>     <public publicId="-//OASIS//DTD DocBook XML CALS Table Model V4.1.2//EN"
>             uri="calstblx.dtd"/>
>   </group>
> 
>   <public publicId="-//OASIS//DTD DocBook MathML Module V1.0//EN"
>       uri="http://www.oasis-open.org/docbook/xml/mathml/1.0/dbmathml.dtd"/>
> 
>   <nextCatalog catalog="stylesheets.xml"/>

Filename should be "stylesheet.xml" no "stylesheets.xml" to point to the 
second catalog file.

>     6. XML Catalog Entries
> 
> Each catalog entry file consists of some number of catalog entries. Catalog 
> entries can be identified by the namespace name defined by this Committee 
> Specification.

May be I miss something because I joined TC just recently, but is it 
really *optional* for catalog entries to be in namespace? Or should the 
sentence be "Catalog entries must be identified ..."

> Elements and attributes from other namespaces are are allowed, but they must be 

"are are" -> "are"

And one final question which is also probably caused by my lack of 
knowledge of previous specification evolution. All schemas for catalog 
entry files (DTD, WXS, RNG) contains in public and system identifiers 
version number 1.0, although the specification describes V1.1 of XML 
Catalogs. I suppose that this is correct and that you have previously 
agreed on not changing these identifiers because V1.0 catalog files can 
be still validated against extended V1.1 schemas. But it looks little 
bit confusing at the first glance. May be adding something like the 
following sentence at the end of Section 9 could clarify this:
"Because catalog entry files that are conforming to the previous XML 
Catalogs Committee Specification 1.0 are also conforming to this 
Committee Specification, OASIS Entity Resolution Technical Committee 
decided not to change system and public identifiers of schemas that 
formally describe grammar of catalog entry files. This decision should 
made it easier to manage transition to this newer version of Commitee 
Specification."

Anyway I don't want to slow down whole standardization process, so 
please ignore this 1.0 vs. 1.1 issue as you like. I know that it is my 
fault that I joined this TC too late so I don't have necessary 
historical background.

					Jirka

-- 
------------------------------------------------------------------
   Jirka Kosek     e-mail: jirka@kosek.cz     http://www.kosek.cz
------------------------------------------------------------------
   Profesionální školení a poradenství v oblasti technologií XML.
      Podívejte se na náš nově spuštěný web http://DocBook.cz
        Podrobný přehled školení http://xmlguru.cz/skoleni/
------------------------------------------------------------------

S/MIME Cryptographic Signature