[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message]

Re: Namespaces, modules and architectures paper available

• From: Paul Prescod <papresco@t...>
• To: Charles@S...
• Date: Wed, 04 Feb 1998 15:39:49 -0500

Charles F. Goldfarb wrote:
> 
> As part of the revision we are also considering scoping of declarations;
> possibly by allowing an internal subset for an element type declaration.
> 
> <!ELEMENT foo (some|model|or|other) [
> <!ENTITY % module1 "some location" MODULE>%module1;
> <!-- Module1 only exists within foo elements. -->
> <!ELEMENT bar (#PCDATA)>
> <!-- As do bar elements. -->
> ]>
> 
> As with parameter passing, scoping declarations, if desirable, will be desirable
> with or without modules.

After thinking this through, I am a little disturbed by the proposal
above. To me, it implies a deep-ish changes to the SGML processing model
that a module/namespace proposal does not. Consider that in a
module/namespace proposal, every element type has a single, fully
qualified name. Unqualified references are merely "short form
references"  (not to be confused with "short references") -- they are a
short form for the full thing. Going from an unqualified instance to a
fully-qualified one is a purely syntactic operation.

But I'm not sure how I would refer to elements in the scheme above.
Let's say I am writing a stylesheet. How do I differentiate betwen
[1]"FOO"s with "BAR" parentage and [2]elements conforming to the element
type "FOO" that can only exist in "BAR". 

[1]
<!ELEMENT BAR (FOO)>
<!ELEMENT FOO EMPTY>
...
<FOO/>
<FOO/>
<BAR><FOO/><BAR>

Here all FOOs refer to the same element type.

[2]
<!ELEMENT FOO EMPTY>
<!ELEMENT BAR (FOO)[
<!ELEMENT FOO EMPTY>
]>
...
<FOO/>
<FOO/>
<BAR><FOO/><BAR>

Here all FOOs refer to different element types.

To me, there is a subtle but important difference. A scoped namespaces
proposal makes SGML (more) context dependent at the *syntactic* level,
but a scoped declarations proposal makes it context dependent at the
*semantic* level. There exists no "context free" expansion. I don't yet
know if this will cause Bad Side Effects. But right now I can't yet
imagine many uses for this feature *other than* the kind of element type
namespace scoping that could be accomplished completely in a modules
proposal. 

If there are no other important uses for this feature then I would
rather stick with the more strictly syntactic module structure and leave
this contextual declaration stuff out. But maybe there are important
uses for this that I have not considered. 

Note that I can *totally* imagine why you would want to scope an entity
declaration or notation declaration to an element, but not to an element
type. I think that the former should be a high priority, but don't
really understand the need for the latter.

 Paul Prescod
--
http://itrc.uwaterloo.ca/~papresco

xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@i...
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/
To (un)subscribe, mailto:majordomo@i... the following message;
(un)subscribe xml-dev
To subscribe to the digests, mailto:majordomo@i... the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@i...)

• References:
  • Namespaces, modules and architectures paper available
    • From: Paul Prescod <papresco@t...>
  • Re: Namespaces, modules and architectures paper available
    • From: Paul Prescod <papresco@t...>

• Prev by Date: Re: Namespaces, Architectural Forms, and Sub-Documents
• Next by Date: Re: Namespaces, Architectural Forms, and Sub-Documents
• Previous by thread: Re: Namespaces, Architectural Forms, and Sub-Documents
• Next by thread: Namespaces, etc.
• Index(es):
  • Date
  • Thread