Home. 
.

transparent

transparent

transparent

Altova Mailing List Archives


Re: [xml-dev] RE: Namespace use cases

From: Robert Koberg <rob@------.--->
To: "Jim Tivy" <jimt@----------.--->
Date: 7/10/2009 1:15:00 AM
On Jul 9, 2009, at 5:59 PM, Jim Tivy wrote:

> I would love to hear of some success or horror stories of multi- 
> namespaces
> in authoring content.  Anyone out there doing this in DITA, DocBook,  
> open
> office...
>
> What ever happened to the compound document?

We do it. Our content pieces usually consist of a custom root element  
to define the content type (and to provide easy xsl:template/@match).  
Then the majority is XHTML unless a custom inline or block level  
element would work better for the authoring experience. We use the  
core XHTML attributes on the custom elements, usually, and add what is  
needed, but don't add custom attributes to the XHTML elements. We made/ 
make custom XML Schemas that mix custom elements/attributes with a  
subset of XHTML. This allows for really simple XSL templating where a  
good percentage can be passed through the XSL identity template and  
the gets defaulted to span|div calss="{local-name()" but overridden  
when needed. (This is one of the beauties of XSL that cannot be easily  
repeated in XQuery.)

When I witness these debates/conversations people seem to speak for  
different vantage points:
* the XML parser/processor developer type
* the technical specialist who might choose or define schemas
* the authors who write XML in a text editor with no IDE help
* the authors who use tools to write XML (WYSIWYG or IDE)

In my experience, using Xopus and some simple forms, the authors don't  
know and rarely care if the behind the scenes document is in XML. I  
fall into the tech specialist camp and work for the authors who use  
tools. For me, I don't see a problem with namespaces...

best,
-Rob


>
> -----Original Message-----
> From: Micah Dubinko [mailto:micah.dubinko@m...]
> Sent: Thursday, July 09, 2009 5:35 PM
> To: Jim Tivy
> Cc: 'Michael Kay'; 'Kurt Cagle'; 'XML Developers List'
> Subject: Namespace use cases
>
>
>
> On Jul 8, 2009, at 2:07 PM, Jim Tivy wrote:
>
>> But how well they address all use cases I do not know.  I would be
>> interested to hear about use cases where Xml namespaces fail and
>> rough sketches of better technologies.
>>
>> Jim
>
> What are the actual (as opposed to supposedly "common knowledge")
> contemporary use cases for a namespacing mechanism (in light of
> current discussion, as needed in HTML)? My informal research shows
> that the use cases used in introductory materials to explain XML
> namespaces are normally very contrived.
>
> Perhaps it's time to come up with a new list?
>
> -m
>
>
>
> _______________________________________________________________________
>
> 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



transparent
Print
Mail
Like It
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.

.
.

transparent

transparent