[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] Re: Venetian Blinds vs Garden of Eden patterns for industry st
Hi David, It should be ns1:root/a/b/ns2:root/b as Philip says because in the scheme I described a and b were unqualified. As such there's no difference in name between b in ns1 and b in ns2 as there would be if they were qualified. I think Philip is right about the issues. It's down to the limitations in XPath expressibility. You need to say something like: b whose qualified parent is in namespace ns1. Sort of b[qualified-parent-ns()=ns1]! Pete Cordell Codalogic Ltd Interface XML to C++ the easy way using C++ XML data binding to convert XSD schemas to C++ classes. Visit http://codalogic.com/lmx/ or http://www.xml2cpp.com for more info ----- Original Message ----- From: "David" <dlee@calldei.com> To: <xml-dev@lists.xml.org> Sent: Thursday, October 28, 2010 1:51 PM Subject: Re: Venetian Blinds vs Garden of Eden patterns for industry standards XML Schemas I guess I still dont get the problem. Wouldn't you just do ns1:root/ns1:a/ns1:b/ns2:root/ns2:b and be done with it ? But thats ok I dont have to "get it" :) David A. Lee dlee@calldei.com http://www.xmlsh.org On 10/28/2010 8:40 AM, Philip Fennell wrote: > David wrote: > >> I dont get this last bit, could you expound please ? > I was extrapolating from Pete's example with the 'context' wrapper for a > namespaced fragement that a compound XML document that used the 'context' > method of binding namespaces to fragments would make transforming such a > document very difficult because you could end up with XPath select > expressions that looked like this: > > ns1:root/a/b/ns2:root/b > > and where you night be using a template match on b you'd have to then > qualify that match with the appropriate namespace prefix which wouldn't > look like the path you used in the select. I just think it'd be much > harder to read. May be a little less to type but it'd be more ambiguous. > > Regards > > Philip Fennell > Consultant > MarkLogic Corporation > Mobile +44 (0) 7824 830 866 > email Philip.Fennell@marklogic.com > web www.marklogic.com > > This e-mail and any accompanying attachments are confidential. The > information is intended solely for the use of the individual to whom it is > addressed. Any review, disclosure, copying, distribution, or use of this > e-mail communication by others is strictly prohibited. If you are not the > intended recipient, please notify us immediately by returning this message > to the sender and delete all copies. Thank you for your cooperation. > > > ________________________________________ > From: David [dlee@calldei.com] > Sent: 28 October 2010 13:16 > To: xml-dev@lists.xml.org > Subject: Re: Venetian Blinds vs Garden of Eden patterns for > industry standards XML Schemas > > I dont get this last bit, could you expound please ? > > "Within an XSLT transform that'd be a nightmare." > > In XSLT or XQuery the namespace is on every node reguardless of if its > physically there in the text representation. So why does it matter if the > text representation has more or less of them ? > You can extract fragments of a complex multi-namespace tree and the output > result will properly add the required namespaces to disambiguate the > results. > > > > David A. Lee > dlee@calldei.com > http://www.xmlsh.org > > > On 10/28/2010 7:59 AM, Philip Fennell wrote: >> Pete wrote: >> >>> That way you only ever have one namespace declaration (ignoring QName >>> issues) irrespective of the types you use from other namespaces, and you >>> only have the root element as qualified. So your XML instance looks >>> like: >>> <myNS:root xmlns:myNS="abc"> >>> <element1> >>> <elementWithTypeDefinedInAnotherNamespace> >>> </elementWithTypeDefinedInAnotherNamespace> >>> </element1> >>> </myNS> >>> The instance is appropriately tagged with it's namespace, but it's all >>> clearly done in one place and there's no other namespace gotchas to >>> worry >>> about. >> I think I see what your trying to do but surely with the above approach >> you are going to have problems when processing fragments of the document >> because you'll lose the context if the fragments are taken as-is. I >> presume, to counter that you're talking about having the 'context' or >> 'root' wrapper being used to contain any fragment of the document which >> means that the container element's content model must allow all possible >> elements, from the schema, as children (or may be a defined sub-set of >> all). In more complex compound documents (XHTML + XForms or XSLT + XHTML >> + XForms) that'd introduce a lot of noise into the document and add a >> different kind of complexity where you're switching namespaces more >> frequently as you traverse the tree in and out of context wrappers. From >> a readability point of view you'd be constantly having to scan back up >> the tree to get you namespace context. Within an XSLT transform that'd be >> a nightmare. >> >> Regards >> >> Philip Fennell >> Consultant >> MarkLogic Corporation >> Mobile +44 (0) 7824 830 866 >> email Philip.Fennell@marklogic.com >> web www.marklogic.com >> >> This e-mail and any accompanying attachments are confidential. The >> information is intended solely for the use of the individual to whom it >> is addressed. Any review, disclosure, copying, distribution, or use of >> this e-mail communication by others is strictly prohibited. If you are >> not the intended recipient, please notify us immediately by returning >> this message to the sender and delete all copies. Thank you for your >> cooperation. >> >> >> >> >> >> ________________________________________ >> From: Pete Cordell [petexmldev@codalogic.com] >> Sent: 28 October 2010 11:16 >> To: xml-dev@lists.xml.org >> Subject: Re: Venetian Blinds vs Garden of Eden patterns for >> industry standards XML Schemas >> >> One thing I'm surprised is not more popular is to always use Venetian >> Blind, >> even across namespaces, BUT make local elements unqualified, i.e. use >> elementFormDefault="unqualified". >> >> That way you only ever have one namespace declaration (ignoring QName >> issues) irrespective of the types you use from other namespaces, and you >> only have the root element as qualified. So your XML instance looks >> like: >> >> <myNS:root xmlns:myNS="abc"> >> <element1> >> <elementWithTypeDefinedInAnotherNamespace> >> </elementWithTypeDefinedInAnotherNamespace> >> </element1> >> </myNS> >> >> The instance is appropriately tagged with it's namespace, but it's all >> clearly done in one place and there's no other namespace gotchas to worry >> about. >> >> The approach mirrors JSON's response to "there's nothing like XML >> namespaces >> in JSON." >> >> I think the issue is that the interpretation of a element depends on the >> context provided by the parent and XSLT and other XPath technologies have >> difficulty with that. >> >> Spot the outsider! >> >> Pete Cordell >> Codalogic Ltd >> Interface XML to C++ the easy way using C++ XML >> data binding to convert XSD schemas to C++ classes. >> Visit http://codalogic.com/lmx/ or http://www.xml2cpp.com >> for more info >> ----- Original Message ----- >> From: "Pete Cordell"<petexmldev@codalogic.com> >> To:<xml-dev@lists.xml.org> >> Sent: Thursday, October 28, 2010 10:58 AM >> Subject: Re: Venetian Blinds vs Garden of Eden patterns for >> industry standards XML Schemas >> >> >>> FWIW I would use: >>> >>> <xs:element name="" type=""/> >>> >>> (i.e. Venetian Blind) where type is within the same namespace/schema as >>> the element, and: >>> >>> <xs:element ref=""/> >>> >>> (i.e. Salami Slice) when the element(/type) being accessed is in a >>> different namespace. >>> >>> To give it a name I'll call it Venetian Slice! >>> >>> By analogy to a class interface, I see the global elements as the public >>> members of an interface, and the global types as the private members. >>> The >>> interface should only publically expose what it has to, and Venetian >>> Blind >>> provides a non-narrative way to express that. Accessing a new namespace >>> is analogous to accessing a new class, and so the public interface (i.e. >>> global elements) of that namespace have to be used. >>> >>> That should open up the discussion! >>> >>> Pete Cordell >>> Codalogic Ltd >>> Interface XML to C++ the easy way using C++ XML >>> data binding to convert XSD schemas to C++ classes. >>> Visit http://codalogic.com/lmx/ or http://www.xml2cpp.com >>> for more info >>> ----- Original Message ----- >>> From: "Dennis Sosnoski"<dms@sosnoski.com> >>> To:<xml-dev@lists.xml.org> >>> Sent: Thursday, October 28, 2010 6:41 AM >>> Subject: Re: Venetian Blinds vs Garden of Eden patterns for >>> industry standards XML Schemas >>> >>> >>>> If you're thinking of using data binding for working with the data in >>>> applications I'd strongly recommend a Venetian Blinds approach. Most >>>> data binding approaches turn Garden of Eden into an amorphous foam of >>>> tiny classes - which is, after all, exactly what Garden of Eden >>>> represents in XML terms. >>>> >>>> Associating the name "Garden of Eden" with this concept of pureed >>>> structure was excellent marketing, but doesn't really give the right >>>> impression. I'd suggest "Element Soup" as an alternative. :-) >>>> >>>> - Dennis >>>> >>>> >>>> On 10/28/2010 05:31 AM, Lech Rzedzicki wrote: >>>>> Hi all. >>>>> >>>>> I am now involved in developing the next iteration of schemas to >>>>> standardise information storage and exchange for trademarks and design >>>>> (there is also some cooperation with patent people). >>>>> The current standards (TM-XML and DS-XML) use a venetian blind pattern >>>>> because it nicely mimics OO model, so it's easy to generate classes >>>>> and objects, also it hides element definitions so there's no conflicts >>>>> when processing them. Finally the naming convention (not my idea) >>>>> means that the element names are not reusable anyway. >>>>> Some people are now proposing that we move to "Garden of Eden" design >>>>> patter, but I don't see that as a particularly smart move in the >>>>> context of our domain. >>>>> I have noticed that many of the schemas in the industry, for instance >>>>> UBL have gone for Garden of Eden first and and later reverted to >>>>> Venetian Blinds. >>>>> I am very interested in some thoughts from the trenches as to why one >>>>> or the other approach might be more useful in a committee driven >>>>> standards with contributors from different domains. >>>>> >>>>> No need to point me to google either - I have read all the articles >>>>> about it [1,2,3] and authored schemas that are in production now both >>>>> ways, but still unconvinced either way... >>>>> >>>>> >>>>> References: >>>>> >>>>> [1] A slideshows on various approaches: >>>>> http://dret.net/lectures/xml-fall08/xsd-2#(11) >>>>> [2] http://www.xfront.com/GlobalVersusLocal.html - schema best >>>>> practices >>>>> [3] http://www.ibm.com/developerworks/xml/library/x-schemascope/ >>>>> etc... >>>>> >>>>> _______________________________________________________________________ >>>>> >>>>> 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@lists.xml.org >>>>> subscribe: xml-dev-subscribe@lists.xml.org >>>>> 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@lists.xml.org >>>> subscribe: xml-dev-subscribe@lists.xml.org >>>> 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@lists.xml.org >> subscribe: xml-dev-subscribe@lists.xml.org >> 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@lists.xml.org >> subscribe: xml-dev-subscribe@lists.xml.org >> 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@lists.xml.org > subscribe: xml-dev-subscribe@lists.xml.org > 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@lists.xml.org > subscribe: xml-dev-subscribe@lists.xml.org > 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@lists.xml.org subscribe: xml-dev-subscribe@lists.xml.org List archive: http://lists.xml.org/archives/xml-dev/ List Guidelines: http://www.oasis-open.org/maillists/guidelines.php
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] |
PURCHASE STYLUS STUDIO ONLINE TODAY!Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced! Download The World's Best XML IDE!Accelerate XML development with our award-winning XML IDE - Download a free trial today! Subscribe in XML format
|