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

Re: Namespaces Not Necessarily Unrepentant Evil

• From: matt@v...
• To: David.Rosenborg@x...
• Date: 28 Aug 1998 12:26:01 -0700
• Date: Fri, 28 Aug 1998 12:26:01 -0700 (PDT)

Yes, and in fact there is a construct in the Veo Schema language to
address this.  In essence you declare foreground and background as
instances of rgb, and the rest is magic.  I will make my slides from
Montreal public RSN (life has been busy this week) and then we can
discuss it at greater length.

Matthew Fuchs
matt@v...

> One problem I see with names in XML is that there is really only
> type names (except for attribute names).
> 
> In programming languages you normally have at least both variable
> names and type names. Just type names work if the data you are
> dealing with is sequential in some sense. This is often
> the case in traditional documents. For example, a document may
> consist of a sequence of chapters which in turn consist of
> sequences of paragraphs. In this case, just type is enough.
> There would be little meaning in naming the individual paragraphs.
> This is analogous to arrays in programming languages.
> 
> The problem arises when you start to use XML for other
> kind of data (and more-than-basic documents too, for that matter).
> 
> Imagine the following hypothetical example of a GUI component
> encoded in XML:
> 
> <text-pad>
>   <color><rgb red="0" green="0" blue="0"/></color>
> 
>   <p>Some default text</p>
> </text-pad>
> 
> In this case you can think of color as a name of an "attribute"
> being of type color. Fine, often the name and the type can be
> the same.
> 
> Now, if I want a second color:
> 
> <text-pad>
>   <foreground><rgb red="0" green="0" blue="0"/></foreground>
>   <background><rgb red="0" green="0" blue="0"/></background>
> 
>   <p>Some default text</p>
> </text-pad>
> 
> Clearly the foreground and background names are only "attribute" names,
> i.e. named instances of colors, and not type names. The type is still
> color but you cannot express this relationship/distinction
> easily in a DTD. Also, from a data perspective, the order of the
> two is not interesting.
> 
> You could argue that you should use real XML attributes in those
> situations, and rgb colors can indeed be encoded as strings,
> but this is just a simple example. The types could be far more
> complex.
> 
> So, I guess AF can be used for this, but it isn't clean enough
> in my opinion. First, it requires you to use copy-paste
> to really us it. Secondly, AF doesn't make the distinction
> between types of elements and names of instances of element types.
> In fact, nor does the other ongoing schema activities (that I know of).
> 
> What I would like to express is: (in pseudo language/syntax)
> 
> In Namespace MyNS declare
> 
>   abstract ElementType Color;
> 
>   ElementType TextPad as
>     foreground of type Color;
>     background of type Color;
> 
>     (TextItem*)
>   end
> 
>   ElementType Rgb implements Color as
>     attribute red of type Integer;
>     attribute green of type Integer;
>     attribute blue of type Integer;
>   end
> 
> end
> 
> ...
> 
> text-pad of type MyNS:TextPad;
> 
> In such an environment you wouldn't have to rewrite the
> element type definitions to use your own names on the actual instances.
> 
> I don't claim these are any new thoughts at all, I just haven't
> come across this topic on this list before, but then, I haven't
> read everything.
> 
> The reason why I brought this up in this thread is that I think
> the problem above is a common problem, and that you often try to solve
> it with namespaces and/or architectural forms. It is IMHO
> a less than optimal approach.
> 
> Any thoughts?
> 
> Cheers,
> 
> </David>
> 
> ______________________________________________________________________
> David Rosenborg                                 OM Exchange Technology
> 
> 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...)
> 
> 


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:
  • Re: Namespaces Not Necessarily Unrepentant Evil
    • From: David Rosenborg <David.Rosenborg@x...>

• Prev by Date: Re: Constraints on Attvalues
• Next by Date: XSL: scripting v/s rewriting
• Previous by thread: Re: Namespaces Not Necessarily Unrepentant Evil
• Next by thread: Re: Namespaces Not Necessarily Unrepentant Evil
• Index(es):
  • Date
  • Thread