Altova Mailing List Archives


RE: [xml-dev] To namespace or not to Namespace ....

From: "Dowling, Nora M." <ndowling@-----.--->
To: David <dlee@-------.--->, "xml-dev@-----.---.---" <-------@-----.---.--->
Date: 4/7/2010 5:57:00 PM
FWIW, I actually like that you always know where an XML construct is coming from.  That way, you are sure that paragraph is paragraph is paragraph no matter what type of document you are editing. Or at least that it is Common's paragraph and not anybody else's. And with XML namespaces, there's no reason you couldn't change the prefixes to something shorter, e.g., t1:, c:, l:, etc. 

-Nora Dowling

-----Original Message-----
From: David [mailto:dlee@c...] 
Sent: Wednesday, April 07, 2010 1:43 PM
To: xml-dev@l...
Subject: Re: [xml-dev] To namespace or not to Namespace ....

Good point Liam, the "hating you" part I forgot.  Your right.
If the XML has to look like

<type1:section>
<common:paragraph>Paragraph <linking:alink/> text </common:paragraph>
</type1:section>

Instead of

<section>
<paragraph>Paragraph <alink/> text </paragraph>
</section>


They (and I) *will* hate me.

Ug.

Can this be done by an inclusion at the XSD level ?
So I can atleast get code reuse ?
If not even "documentation reuse" would be useful, that is "document" 
the fact that various tags are "shared" across schemas even if its not 
semantically enforced.







-------------------------
David A. Lee
dlee@c...
http://www.calldei.com
http://www.xmlsh.org


On 4/7/2010 1:33 PM, Liam R E Quin wrote:
> On Wed, 2010-04-07 at 13:15 -0400, David wrote:
>    
>> [...]
>>      
>    
>>   For example all the schemas have a concept of
>> linking, a concept of paragraphs etc ... while the majority of the
>> structure is domain specific, it would be nice to share the common parts.
>> Which all roads leads to ....
>>
>> Namespaces !!!!
>>      
> In the SGML world it generally led to a shared element pool, as Eve
> Maler liked (likes?) to call it.
>
> Once you make authors deal with
>      <spec1:section>
>        <common:title>..</common:title>
>        <spec2:topic>
>          <common:purpose>
>            <common:paragraph>
>            <spec2:step>
>             <spec9:part-number>...
> they will hate you and make you wear shoes for the rest of your life.
>
> But you are right, it's technically possible. In many programming
> languages, namespaces would let you say,
>
>      import common;
>      import section from spec1;
>      import topic, step from spec2;
>      import part-number from spec9;
>
> and then use unqualified names. That sort of functionality can be a
> great help, but it is not what XML namespaces do today.
>
> Liam
>
>    

_______________________________________________________________________

XML-DEV is a publicly archived, unmoderated list hosted by OASIS
to support XML implementation and development. To minimize
spam in the archives, you must subscribe before posting.

[Un]Subscribe/change address: http://www.oasis-open.org/mlmanage/
Or unsubscribe: xml-dev-unsubscribe@l...
subscribe: xml-dev-subscribe@l...
List archive: http://lists.xml.org/archives/xml-dev/
List Guidelines: http://www.oasis-open.org/maillists/guidelines.php


_______________________________________________________________________

XML-DEV is a publicly archived, unmoderated list hosted by OASIS
to support XML implementation and development. To minimize
spam in the archives, you must subscribe before posting.

[Un]Subscribe/change address: http://www.oasis-open.org/mlmanage/
Or unsubscribe: xml-dev-unsubscribe@l...
subscribe: xml-dev-subscribe@l...
List archive: http://lists.xml.org/archives/xml-dev/
List Guidelines: http://www.oasis-open.org/maillists/guidelines.php

Disclaimer

These Archives are provided for informational purposes only and have been generated directly from the Altova mailing list archive system and are comprised of the lists set forth on www.altova.com/list/index.html. Therefore, Altova does not warrant or guarantee the accuracy, reliability, completeness, usefulness, non-infringement of intellectual property rights, or quality of any content on the Altova Mailing List Archive(s), regardless of who originates that content. You expressly understand and agree that you bear all risks associated with using or relying on that content. Altova will not be liable or responsible in any way for any content posted including, but not limited to, any errors or omissions in content, or for any losses or damage of any kind incurred as a result of the use of or reliance on any content. This disclaimer and limitation on liability is in addition to the disclaimers and limitations contained in the Website Terms of Use and elsewhere on the site.