OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

 


 

   Re: [xml-dev] Where have the element types gone?

[ Lists Home | Date Index | Thread Index ]

Dare Obasanjo wrote:


>>I would rather say that the main "gain" is additional complexity.
> 
> I admit there is additional complexity but it brings with it more
> flexibility and the ability to me more expressive about the contents of an
> element. From what I've seen the growing complexity of XML is disliked by
> many (myself included) but in the case of schemas versus DTDs, I think the
> right trade off between complexity and utility was made.


It's bringing additional possibilities, for sure, but I don't see the 
advantage of using it in simple cases where it's not required.

In the example which I had chosen, I don't see any additional benefit of 
not using the element type to identify the ISBN number.

 

> Using element types to identify the elements is one thing but infering
> datatype information from the presence of an element type given that a
> schema for the document exists is now a faux pas. It seems that you are
> saying that old apps could make assumptions about the type information of
> elements without necessary going through validation while with the existence
> of schemas it is now more important that validation occurs. I fail to see
> this as a drawback unless of course it is some sort of performance sensitive
> application in which case one cannot have one's cake and eat it too.


I think I see the origin of the difference of perception. To me, it's 
assuming that all the applications will use a schema even if one is 
provided which is a faux pas.

I have a very "document centric" vision of XML and to me a schema is 
just one way to describe a class of document (together with "human" 
documentation, other schema languages, programs, XSLT transformation). 
In other words, what's important IMO is the document. The other stuff 
are only ways to describe and process the document that some 
applications will use and other not use and which will evolve when new 
versions of these tools will emerge.

Relying on these additions should be, IMO, done only when required but 
should be avoided when there is no additional value.

> 
> Secondly, no one is saying that it is now wrong call "pub:isbn" "pub:isbn"
> but instead that one can seperate the type information from the actual
> element so as to reuse the type declaration the same way one creates
> multiple instances of a class. I also wanted to note that re your earlier
> comment
> 
> 
>>Let's assume I am creating a vocabulary for book publishing and that I
>>create:
>>1) A "pub:isbn" datatype
>>2) A "pub:isbn" element
>>
> 
> Most prudent schema authors would avoid using the same name for both the
> datatype and the element name to avoid confusion. At least that has been my
> experience.


I don't see why. They are different concepts, one belongs to the markup 
and the other to a specific schema language so there should be no 
confusion ;=) ...

Thanks for your mails, they help me understand your position!

Eric


> --
> THINGS TO DO IF I BECOME AN EVIL OVERLORD #15
> I will never employ any device with a digital countdown. If I find that such
> a device is absolutely unavoidable, I will set it to activate when the
> counter
> reaches 117 and the hero is just putting his plan into operation.
> 
> 
> 
> _________________________________________________________
> Do You Yahoo!?
> Get your free @yahoo.com address at http://mail.yahoo.com
> 
> 
> 



-- 
See you in Orlando for XML 2001.
                                     http://www.xmlconference.net/xmlusa/
------------------------------------------------------------------------
Eric van der Vlist       http://xmlfr.org            http://dyomedea.com
http://xsltunit.org      http://4xt.org           http://examplotron.org
------------------------------------------------------------------------





 

News | XML in Industry | Calendar | XML Registry
Marketplace | Resources | MyXML.org | Sponsors | Privacy Statement

Copyright 2001 XML.org. This site is hosted by OASIS