OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

entity-resolution message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]


Subject: Re: XML Catalogs Working Draft 12 Jun 2001


/ Daniel Veillard <veillard@redhat.com> was heard to say:
|     - could you specify whether attributes can be anchored in the
|       namespace (e.g. <cat:catalog cat:prefer="system" cat:id="top"
| 	   xmlns:cat="urn:oasis:names:tc:entity:xmlns:xml:catalog"> is
| 	   allowed or forbidden) ?
|       I suggest to make it explicit

I believe our intent was that attributes would be in the element
partition, not global:

   <cat:catalog prefer="system" id="top"
                xmlns:cat="urn:oasis:names:tc:entity:xmlns:xml:catalog">

I think it should be an error to use them in the global partition.

|     - 4. Using Catalogs
|       2/ prefer attribute referenced before being defined, i suggest making
|       a link to the definition (same for xml:base related prose).

Fair point.

|     - 5.1. The xcatalog File
|       I really dislike this mechanism. It breaks the XML processing model

I'm not a huge fan either.

|       If the author wants to signal the presence of a catalog use a
|       PI (like the xml-stylesheet one) at least it's clearly flagged

We originally had a PI for this, but that has its own set of problems.
Specifically, you have to have started parsing before you see it, so
if you need it to find the doctype, you're hosed.

|     - as already pointed to Norm, the spec lacks a full example, this
|       would help (a small one in 4 Using Catalogs would be nice or making
|       the one in 3 a complete example)

Right.

|     - "The nextCatalog element" ... this is used multiple time along the
|       spec and leads to the idea that only one nextCatalog is allowed while
|       global catalogs would definitely need the possibility of a tree
|       of catalogs, I hope it's possible.

Yes, you can have as many as you like, I'll make that clearer.

|     - 7.1.1. Input to the Resolver 
|       what do you mean by "unwrapping the URN" ? example please !

Ok. Look at the Internet Draft, too, that may help.

|     - the spec in general would benefits from a set of "definitions"
|       and links to it from the usages. Example
|       resolution, delegation, URI reference, external identifier,
|       base URI

I'll see what I can do.

|     - I haven't checked yet but I hope the algorithms in 7.1.2 and 7.2.2
|       can be implemented without too much troubles with a single hash table
|       for all entries based on a set of fully loaded catalog tree. I hope
|       steps 6 and 7 won't force a too complex implementation.

It absolutely cannot be implemented with a hash table. I think you
really have to build a linear structure and walk over it (sometimes
more than once).

|     - 8 don't specify very clearly hoe to define that a given resource
|       is a catalog. Is the check 
|         - it's XML
| 	and
| 	- there is a root node
| 	  - its name is catalog
| 	  - its namespace name is "urn:oasis:names:tc:entity:xmlns:xml:catalog"
|       the one the applications should implements ?
|       Anyway this should be precised.

I think that's the algorithm.

|   Sorry, this grew up a bit more than expected initially (it's good to
| be on the other side sometimes ;-)

lol. Thanks for the comments.

                                        Be seeing you,
                                          norm

-- 
Norman.Walsh@Sun.COM   | A hen is only an egg's way of making another
XML Standards Engineer | egg.--Samuel Butler (II)
Technology Dev. Group  | 
Sun Microsystems, Inc. | 


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]


Powered by eList eXpress LLC