W3C home > Mailing lists > Public > w3c-sgml-wg@w3.org > June 1997

RE: Update on namespaces

From: Andrew Layman <andrewl@microsoft.com>
Date: Thu, 26 Jun 1997 17:31:19 -0700
Message-ID: <7BB61B44F197D011892800805FD4F792DECB23@RED-03-MSG.dns.microsoft.com>
To: w3c-sgml-wg@w3.org
David Durand wrote some mail (below) that reflects a misunderstand of
what I intend from namespaces.  Without getting into many of the other
interesting issues raised here and elsewhere, I want to clear up this
one point:

Namespaces does not mean that suddenly any element is valid anywhere.

I absolutely am not suggesting that the use of namespace means that
every element suddenly has an implicit content model of "ANY".

I imagine merely something along the following lines:

Namespace A (mineral) has

<!-- Chemical elements -->
<!ELEMENT Gold>
<!ELEMENT Mercury>

Namespace B (planet) has

<!--The planets -->
<!ELEMENT Mercury>
<!ELEMENT Venus>
<!EMEMENT Earth>

Some instance data has (and I don't mean this to be good DTD design,
just a crude example):

<PlanetaryMineralProspects>
    <PlanetsExplored>
        <planet:Mercury/>
    </PlanetsExplored>
    <MineralsFound>
        <mineral:Mercury/>
    </MineralsFound>
</PlanetaryMineralProspects>

Obviously, the DTD for this could specify that the content model for
PlanetsExplored allows only planet:Mercury, planet:Venus etc.  (The
exact syntax for namespace reference in schemata is yet to be worked
out.)  The key point, however, is that the DTD absolutely does not allow
just any element anywhere. It allows only certain elements within
PlanetsExplored, and different ones within MineralsFound.

An obvious syntax springs to mind:

<!ELEMENT PlanetsExplored ( planet:Mercury? planet:Venus? planet:Earth )
>
<!ELEMENT MineralsFound ( mineral:Mercury? mineral:Gold? ) >

That is, far from defeating validation, namespaces permit use of
multiple, merged schemata while retaining validation.

I hope this clarification is helpful.

--Andrew Layman
   AndrewL@microsoft.com

> -----Original Message-----
> From:	dgd@cs.bu.edu [SMTP:dgd@cs.bu.edu]
> Sent:	Wednesday, June 18, 1997 12:32 PM
> To:	w3c-sgml-wg@w3.org
> Subject:	Re: Update on namespaces
> 
> At 11:28 AM -0500 6/18/97, Matthew Fuchs wrote:
> >> For now, I lean to #3, with AF's a fallback position if there's a
> really
> >> good reason for not doing #3.  Andrew Layman and have agreed to
> cook
> >> up a formal proposal along these lines, which will be forthcoming.
> >>
> >>-- End of excerpt from Tim Bray
> >
> >Occam's razor would indicate going with #2, since we need add
> nothing.  #3 is
> >certainly cool syntactic sugar, but it opens the door to messing with
> the
> >structure of the GI.  I've also suggested a different extension for
> error
> >recovery.
> 
> And the notion that XML should not have any syntax it does not need
> also
> argues for #2. In fact, I have yet to see an answer to the arguments
> of
> myself and others that there is _no_ positive argument for #3, if #2
> can
> meet the need.
> 
> The only argument that I can think of is a knee-jerk opposition to any
> form
> of markup declaration by those members of the web community who _lack_
> any
> experience with structured markup other than HTML. Parsing the entity
> and
> attribute declarations in the DTD subset provides more notational
> power
> than any the hacked-up GI formats that have been proposed, and will be
> required for reliable operation of XML-link anyway.
> 
> Needless to say (as you might guess from my presentation of the
> argument),
> I am not convinced. However, I'd like to see the argument presented in
> rational terms, or another better argument presented. I did reread all
> of
> Andrew Layman's posts to look for the namespace requirements and the
> original post that posed the problem. I did see aan assumption that
> the use
> of architectural forms inherently involves a model of inheritance, but
> nothing that showed a need that could not be met.
> 
> >The next step will be defining regular expressions for parsing the GI
> to
> >determine which extensions are being used.  I don't say  that's good
> or bad,
> >but I suggest it will now be inevitable.
> 
> This is one potential consequence of accepting solution #3, and I
> agree
> that it's not very attractive.
> 
> Even worse is the creation of a DTD escape hatch that makes validation
> impossible under current rules. Furthermore, it is proposed that we
> make
> this change without an analysis of the underlying semantics of the
> syntactic implications of the change. This would be foolhardy and
> irresponsible. You can't create syntax before you analyze the
> semantics
> you're looking for and hope to get it right.
> 
> WF documents are acceptable because they meet a variety of needs, but
> so
> does the notion of valid documents. Re-casting XML so that DTDs are
> essentially meaningless, because another namespace can dump aribtrary
> crap
> into any document anywhere, without declaration, is a bad idea in
> relatively objective terms. It trashes the utility of the DTD for
> those
> purposes that it (imperfectly) meets.
> 
> I remain opposed to the whole notion of special namespace syntax
> absent a
> clear justification of its absolute necessity. Rereading Andrew's
> posts has
> only reconfirmed my impression that no such requirements have been
> articulated so far. I also think that if it _is_ necessary we must
> know
> what effects the new feature will have on validity. Validity does not
> solve
> all problems, but it alleviates many, and making an instance syntax
> that
> cannot be validated against some formal syntactic description throws
> those
> benefits away.
> 
> Sorry to be a bit redundant, but I'm tired of seeing posts like Tim's
> that
> started:
> 
> >The original statement of the requirement by Andrew Layman seems to
> have
> >stood up pretty well under pressure of discussion here, and external
> talk
> >with various interested groups here and there in the W3C and
> engineering
> >groups around the web.
> 
> I think the only thing that we've seen is that some people need
> architectures but don't care for the syntax. I don't think that that's
> a
> reason to trash a significant part of the work we've already done,
> based on
> concrete experience (over the whole group) of multiple decades
> (probably
> more than a century) or markup experience.
> 
> Why did we waste time arguing about content models if we were going to
> add
> the equivalent of a universal "Include #ANY" inclusion exception at
> the
> 11th hour without even considering its effect on the DTD?
> 
>    -- David
> 
> 
> _________________________________________
> David Durand              dgd@cs.bu.edu  \  david@dynamicDiagrams.com
> Boston University Computer Science        \  Sr. Analyst
> http://www.cs.bu.edu/students/grads/dgd/   \  Dynamic Diagrams
> --------------------------------------------\
> http://dynamicDiagrams.com/
> MAPA: mapping for the WWW
> \__________________________
> 
Received on Thursday, 26 June 1997 20:31:26 EDT

This archive was generated by hypermail pre-2.1.9 : Wednesday, 24 September 2003 10:04:44 EDT