More on namespaces and XML schema...

Hello again,

Seeing as the link in the documentation (running under
tomcat) for
lzx.dtd returns a 404 error I had to do a bit of searching
around on the
net. There's a link on the wiki, under 'Editing LZX' that is
also broken
too.

So initialy I tried using the XML Schema (lzx.xsd) and
noticed
immediately:

1) That the form and window elements are not defined in the
schema.


2) There are errors in the schema too:

In the definition of the element 'preloadresource' the name
and resource
attributes are also declared elsewhere in attributeGroup
declarations
referenced directly and indirectly by this element
declaration.


3) If you put the appropriate markup, in the root of you
canvas
document, to identify the schema:

<canvas xmlns="http:/
/www.laszlosystems.com/2003/05/lzx"
        xmlnssi=&q
uot;http:
//www.w3.org/2001/XMLSchema-instance"
        xsi:schemaLocation="http://www.l
aszlosystems.com/2003/05/lzx
../schema/lzx.xsd"
        width="1024"
        height="768">
   ...
</canvas>

You get the following error message form the compiler:


The application could not be compiled due to the following
errors:

Compilation Errors
form.lzx:10:22: Syntax error: the token ":" was
not expected at this
position.
Compilation Warnings

form.lzx:10:22: attribute "schemaLocation" from
namespace
"http:
//www.w3.org/2001/XMLSchema-instance" not allowed
at this point;
ignored
form.lzx:10:22: found an unknown attribute named
"schemaLocation" on
element canvas, check the spelling of this attribute name


This would suggest that not only is Open Laszlo not XML
namespace aware
(see previous e-mail) but neither is it XML Schema aware
either.


Its not that I'm being picky for picky's sake, I actually
like what I've
seen of Open Laszlo so far. Its just that things I'd want
and expect to
work don't.


Regards

Philip Fennell

Thanks for this report.  I have added your message to
[LPP-3179] 
(http:
//jira.openlaszlo.org/jira/browse/LPP-3179) as being
relevant  
to that bug.  We know that the dtd is not accurate and that
the  
namespace is stale.  We hope to address these issues soon.

There are possibly separate issues that should be reported
(the bad  
doc link).  Whether the canvas tag should accept namespace
and schema  
declarations is open to discussion.  Our current philosophy
is that  
LZX is all in a single (implicit) namespace.

On 2007-04-12, at 09:36 EDT, Fennell, Philip wrote:

> Hello again,
>
> Seeing as the link in the documentation (running under
tomcat) for
> lzx.dtd returns a 404 error I had to do a bit of
searching around  
> on the
> net. There's a link on the wiki, under 'Editing LZX'
that is also  
> broken
> too.
>
> So initialy I tried using the XML Schema (lzx.xsd) and
noticed
> immediately:
>
> 1) That the form and window elements are not defined in
the schema.
>
>
> 2) There are errors in the schema too:
>
> In the definition of the element 'preloadresource' the
name and  
> resource
> attributes are also declared elsewhere in
attributeGroup declarations
> referenced directly and indirectly by this element
declaration.
>
>
> 3) If you put the appropriate markup, in the root of
you canvas
> document, to identify the schema:
>
> <canvas xmlns="http:/
/www.laszlosystems.com/2003/05/lzx"
>         xmlnssi=&q
uot;http:
//www.w3.org/2001/XMLSchema-instance"
>         xsi:schemaLocation="http://www.l
aszlosystems.com/2003/05/lzx
> ../schema/lzx.xsd"
>         width="1024"
>         height="768">
>    ...
> </canvas>
>
> You get the following error message form the compiler:
>
>
> The application could not be compiled due to the
following errors:
>
> Compilation Errors
> form.lzx:10:22: Syntax error: the token ":"
was not expected at this
> position.
> Compilation Warnings
>
> form.lzx:10:22: attribute "schemaLocation"
from namespace
> "http:
//www.w3.org/2001/XMLSchema-instance" not allowed
at this point;
> ignored
> form.lzx:10:22: found an unknown attribute named
"schemaLocation" on
> element canvas, check the spelling of this attribute
name
>
>
> This would suggest that not only is Open Laszlo not XML
namespace  
> aware
> (see previous e-mail) but neither is it XML Schema
aware either.
>
>
> Its not that I'm being picky for picky's sake, I
actually like what  
> I've
> seen of Open Laszlo so far. Its just that things I'd
want and  
> expect to
> work don't.
>
>
> Regards
>
> Philip Fennell
>

Thanks for the link.

I've had a quick look at the examples of XPath expressions
in section 3.1 and was rather surprised to see the
following:

myData:/myXML[1]/person[2-3]
myData:/myXML[1]/person[2-]
myData:/myXML[1]/person[-2]

Since when has there been position predicates in XPath that
support ranges?

I'm more that slightly aquainted with the XPath 1 spec and
have been using XPath 2 for a couple of years now and have
never seen this before.


Regards

Philip Fennell

 
 

________________________________

From: Francisco Jose Peredo [mailto:fperedosefintab.gob.mx] 
Sent: 12 April 2007 16:06
To: Fennell, Philip
Cc: laszlo-useropenlaszlo.org
Subject: Re: [Laszlo-user] More on namespaces and XML
schema...


Hi!
Laszlo has "limited support for namespaces"
(basically it ignores them): 
Chapter 36. Data, XML, and XPath
http://labs.openlaszlo.org/legals-night
ly/docs/guide/data-structures.html
(that is from OL 4.0, so I guess none of the previous
versions have more than "limited" support.

Fennell, Philip escribió: 

	Hello again,
	
	Seeing as the link in the documentation (running under
tomcat) for
	lzx.dtd returns a 404 error I had to do a bit of searching
around on the
	net. There's a link on the wiki, under 'Editing LZX' that
is also broken
	too.
	
	So initialy I tried using the XML Schema (lzx.xsd) and
noticed
	immediately:
	
	1) That the form and window elements are not defined in the
schema.
	
	
	2) There are errors in the schema too:
	
	In the definition of the element 'preloadresource' the name
and resource
	attributes are also declared elsewhere in attributeGroup
declarations
	referenced directly and indirectly by this element
declaration.
	
	
	3) If you put the appropriate markup, in the root of you
canvas
	document, to identify the schema:
	
	<canvas xmlns="http:/
/www.laszlosystems.com/2003/05/lzx" <http://w
ww.laszlosystems.com/2003/05/lzx> 
	        xmlnssi=&q
uot;http:
//www.w3.org/2001/XMLSchema-instance" <http://
www.w3.org/2001/XMLSchema-instance> 
	        xsi:schemaLocation="http://www.l
aszlosystems.com/2003/05/lzx
	../schema/lzx.xsd" <http://www.laszlosystems.com/2003/05/lzx../schema/l
zx.xsd> 
	        width="1024"
	        height="768">
	   ...
	</canvas>
	
	You get the following error message form the compiler:
	
	
	The application could not be compiled due to the following
errors:
	
	Compilation Errors
	form.lzx:10:22: Syntax error: the token ":" was
not expected at this
	position.
	Compilation Warnings
	
	form.lzx:10:22: attribute "schemaLocation" from
namespace
	"http:
//www.w3.org/2001/XMLSchema-instance" <http://
www.w3.org/2001/XMLSchema-instance>  not allowed at
this point;
	ignored
	form.lzx:10:22: found an unknown attribute named
"schemaLocation" on
	element canvas, check the spelling of this attribute name
	
	
	This would suggest that not only is Open Laszlo not XML
namespace aware
	(see previous e-mail) but neither is it XML Schema aware
either.
	
	
	Its not that I'm being picky for picky's sake, I actually
like what I've
	seen of Open Laszlo so far. Its just that things I'd want
and expect to
	work don't.
	
	
	Regards
	
	Philip Fennell
	
	
	
	  

Jamesr,

Although your observations on the uses of namespaces are
quite correct
you have missed the point of my original query regarding XML
namespace
support in datapath XPath expressions.

I'd agree that LZX itself can exist without a namespace,
although it
helps when generating using XSLT, and it is unlikely to be
used in
conjunction with other XML applications (except XSLT) but
the problem
that I encountered (and undoubtedly others will too) is that
we do not
always have control over the form of the data that we wish
to
reference/embed in a dataset. If that data uses one or more
namespaces
then it makes unavoidable sense to be able to write XPath
expressions
that include the namespace prefixes to ensure no
ambiguity/mistakes when
resolve those path expressions. That is something else that
namespaces
where designed for too.

The other point about the compiler being namespace/XML
schema aware is a
compiler issue that needs to be addressed if people are
going to be able
to use the schema to aid them in building LZX applications.


Regards

Philip Fennell

________________________________

From: laszlo-user-bouncesopenlaszlo.org
[mailto:laszlo-user-bouncesopenlaszlo.org] On Behalf
Of jamesr
Sent: 13 April 2007 17:16
To: laszlo-user
Subject: Re: [Laszlo-user] More on namespaces and XML
schema...


I'm not sure that anyone is suggesting this, but I feel the
need to
write it anyway. 

Aside from the validation of LZX (which the compiler does by
virtue of..
compiling it) I don't personally see a reason why LZX should
include
namespaces as part of how to build a LZX document.
Namespaces help
delineate area of a document that have different formats. In
the case of
templating languages dealing with HTML, for instance,
namespaces are
used to separate templating instructions from the actual
output, where
those templating instructions are removed by design. In the
case of a
database format, they are very important, since data is
context-free in
the sense that one chunk of data may be completely
orthogonal to the
next in purpose and form.

However, as a language it is not very likely (please,
imagine a scenario
if you will) where LZX will commingle with other languages.
It's like
putting PHP into a Python program. Sure, there are external
interfaces
to allow them to speak, but because each has access to it's
own
resources lexically, you won't see one line of PHP followed
by another
line of python. Consider that in the data world this may be
the case,
but for programming language?

I don't believe that namespaces should come anywhere near
code that
describes programmatic operation. It increases the
complexity of reading
the code and describing problems with no advantage in
allowing
capability to mix declarative statements in a way that makes
sense.

My opinion only, thanks for reading