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: first proposal


/ Lauren Wood <lauren@sqwest.bc.ca> was heard to say:
| > 1. Make all element and attribute names strictly lowercase
| 
| I actually like camel caps, since I think it makes two-word names 
| easier to read (e.g., PublicId rather than publicid).

Matter of taste, I guess. That means we have four choices:

1. All UPPERCASE, as per 9401
2. All lowercase
3. camelCase like XML Schema, Java identifiers, etc.
4. CamelCase like the SGML DocBook DTD (though only because case
   didn't matter)

I prefer 2 and 3 to 1 and 4.

| > This immediately raises some questions:
| > 
| > a. Should we use consistent source/target attribute names?
| 
| You mean, change PublicId and SystemId to "source" and the 
| various href's to "target"? I don't think so.

I wasn't suggesting "source" and "target" literally, just that we
pick consistent names for the left and right hand sides.

I'm not real thrilled with

<public publicid="-//OASIS//DTD DocBook XML V4.1.2//EN"
        href="/share/doctypes/docbook/xml/docbookx.dtd"/>

The "public" in publicid seems redundant and I'm not terribly pleased
with "href" either; this isn't a hypertext reference. Maybe the right
hand side should always be "uri"?

Looking forward, assuming we add some new specific keywords instead of
complete generality, what do we use as attribute names for

<stylesheet ... uri="..."/>
<namespaceName ... uri="..."/>
<schemaLocation ... uri="..."/>

| > c. Can we think of a better name than "extend" for the functionality
| >    of loading an additional catalog? I think "extend" will lead people
| >    to "extensibility" and they'll get confused.
| 
| How about LoadCatalog? A bit longer, but with an obvious 
| meaning. I don't expect people to be editing these things very 
| often, so having names a little longer than necessary to make them 
| easy to remember seems like a good trade-off to me.

Yep. I don't mind long names as long as they're clear. But I'm not
delighted with LoadCatalog, since it's the only one that's got a verb
in it.

Hmmm...off the top of my head...

subordinateCatalog
otherCatalog
alternateCatalog
additionalCatalog
includeCatalog
includedCatalog
importCatalog
importedCatalog

Maybe just 'import'. (The semantics of the CATALOG directive are more
like xsl:import than xsl:include.)

Yes, I think I vote for 'import' all by itself.

                                        Be seeing you,
                                          norm

-- 
Norman.Walsh@East.Sun.COM | Our culture peculiarly honors the act of
XML Technology Center     | blaming, which it takes as the sign of
Sun Microsystems, Inc.    | virtue and intellect.--Lionel Trilling


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


Powered by eList eXpress LLC