Re: XLink 1.1: Schema issues

Henry S. Thompson wrote:
> Please let us know if you are satisfied with this answer,

Definitely not.

> Webb Roberts writes:
>> A better schema implementation would specify ONLY normative
>> components in the spec-defined namespace, and relegate all other
>> content to an explicitly non-normative namespace.
> 
> The whole appendix is non-normative. . .

The appendix is non-normative, but the namespace is normative.

A schema should enforce the rules of the language on which it is
based.  The specification says exactly what artifacts are valid for the
normative namespace.  Why should the schema define non-normative
constructs in the normative namespace?

I will stipulate that the schemas are non-normative.  However, by being
included in the schema, they are being presented to the public as
recommended, or best practice.  The schema defines constructs within a 
normative namespace, so the use of those constructs has implications.

Non-normative entities (such as types, attribute groups, etc) could 
easily be moved to a non-normative namespace.  Such a move will give 
implementors more independence from this specific schema implementation. 
  It would be nice if we could look only at the effect of a schema on 
instances, but many of us use interrelated schemas, and have to look at 
the way schemas work together.

> I'm afraid I don't understand why this would change the situation in 
> any significant way.  The normative prose of the spec. defines the 
> syntax and semantics of the named attributes in the XLink namespace. 
> The non-normative DTD, W3C XML Schema and RelaxNG schema specify the 
> permitted syntax of those attributes.  All three of them define other
>  names, incidental to their primary purpose.  Anyone using or
> referring to these three schemas will depend on _all_ the definitions
> therein, whatever namespace (or none) they are in.

I'm not concerned with internal parts of the implementations, or with 
non-schema implementations, as that's not my area.  I am only concerned 
with externally-visible entities defined by a specification-endorsed 
schema on a normative namespace.  This really comes down to visibility: 
of entities within a normative namespace.

> Any e.g. W3C XML Schema document which imports a copy of Appendix C 
> will depend on its contents, whether they are in the XLink namespace 
> or not. . .

Again, I don't think we need to worry about things in non-normative 
namespaces.  It's the definition of objects in a normative namespace 
that we should be concerned with.  What if we decided to create and use 
lots of entities in the XML namespace?  Would we be playing nicely?  Or 
would we be making life harder for people who have to span multiple 
implementations?

> But if you depended only on xlink:role _as a top-level attribute 
> declaration_ I might run into exactly the same problem if, for 
> example, a subsequent release of the non-normative schema moved all 
> the attribute declarations into appropriately-structured attribute 
> group definitions.

Of course, you could always do work to make things harder.  However, if 
you just defined the namespace to contain the constructs that the 
specification requires, it would make life easier for some of us.

 >> A better schema implmentation would specify ONLY normative
>> components in the spec-defined namespace, and relegate all other
>> content to an explicitly non-normative namespace.
> 
> The whole appendix is non-normative. . .

Of course, but the published schema will become a standard 
implementation, on the normative namespace.

> With respect, I think this would substantially _reduce_ the value of 
> the appendix.  By using named types, the possibility of defining your
>  own e.g. title-equivalent element which is in the substitution group
>  of xlink:title but with a type definition which is a restriction of 
> xlink:titleEltType is supported, which would not be possible if the 
> utility types were not named.

Named types are great, just not in the normative namespace.  Pushing 
them out to non-normative namespace would be a trivial modification to 
the existing schemas.  My goal here is ease of use and restriction for 
implementors.

>> Note that this solution also obviates the requirement to import the
>>  xml namespace.
> 
> I don't understand -- some way of allowing xml:lang where the spec.
> allows it is still required.

The spec doesn't specify the existence of a type "xlink:titleEltType", 
so why define it?  Without that type, there's no need for the import of 
the xml namespace, in this particular schema.

> I appreciate your desire to see this appendix be of maximal value,
> but I think having named type definitions and abstract named element 
> declarations is the best way to achieve this.

Fine.  But please not in the normative namespace.

Thanks,
Webb

-- 
Webb Roberts (webb.roberts@gtri.gatech.edu)
Research Scientist, Georgia Tech Research Institute
Atlanta, GA  (404)407-6181

Received on Tuesday, 24 January 2006 21:05:49 UTC